Re: Re: Why all the different string types?

Am 28.03.2006 um 05:56 schrieb Guy Rouillier:

> Jens Miltner wrote:
>
>>
>> Another thing to consider would be to make the sandbox settings
>> local, i.e. don't use global variables to hold the values: at least
>> MacCvs allows to open more than one sandbox browser simultaneously
>> and currently, it's a bit of a hack to switch settings when a window
>> comes to front (because settings are global in the current
>> implementation).
>
> Jens, thanks for the reply.  I don't use the Mac, so please help me
> understand what you mean by local sandbox settings.  Do these get
> persisted or is their lifetime only while the app instance is running?
> If they get persisted, what differentiates one set from another?   Are
> they connected to a specific project, like non-global settings?  If=20=20
> so,
> could we persist them in the same store that maintains the project=20=20
> settings?

The current implementation already differentiates between "global"=20=20
and "project" settings: when constructing a CPersistent, it takes a=20=20
kClassPersistent argument, which uses the completely non-intuitive=20=20
enum values "kNoClass" and "kAddSettings". Values of type "kNoClass"=20=20
are considered global variables and values of type "kAddSettings" are=20=20
stored on a per-sandbox basis.

In the Mac implementation, the two classes of settings are also=20=20
stored in different locations: the global ones are stored in the=20=20
standard system preference location (kind of similar to the Windows=20=20
Registry), whereas the per-sandbox settings are stored in text files=20=20
in a specific subdirectory of the Mac's Preference folder. Each text=20=20
file contains (among other settings) the sandbox path, so the=20=20
settings can be identified to be connected to that sandbox...
I'm pretty sure the basic mechanism is the same for the other=20=20
platforms, IIRC, even the implementation for the per-sandbox settings=20=20
is shared, the only differences are the location where things are=20=20
stored and the storage format of the global settings.

>
> Perhaps what we should do is use the global settings as the=20=20
> default, and
> allow the project settings to override.  If we do that, I'd like to
> break out Admin-Preferences into two separate menu items: Global
> settings and Project settings.  Having two sets of the same=20=20
> settings in
> a single dialog box would get very confusing.

I think in general, the idea to allow overriding a global setting is=20=20
good, however, there are certainly some settings that you would want=20=20
to toggle globally, i.e. you don't want to check with each sandbox=20=20
whether they have been defined there. You mentioned the cvs=20=20
executable, which is a good example of such a setting...

In general, I think the current classification between global and per-=20
sandbox settings isn't too bad, the only thing missing is a defined=20=20
way to specify your default settings and allow to override specific=20=20
settings per-sandbox. Right now, you can specify which settings to=20=20
use as the starting point when browsing a new sandbox (at least=20=20
that's how it works in MacCvs), but once you picked the settings,=20=20
this contains all settings, i.e. changing the default settings won't=20=20
affect any existing sandbox...

>
> Let's be explicit.  In gCvs, on the Preferences dialog is a Globals=20=20
> tab
> with the following settings:
>
> Checkout read=3Donly
> Use TCP/IP compression
> Quiet mode
> Dirty files support
> Prune empty directories
> Supply control when adding files
>
> In WinCvs, I see
>
> File attribute (equivalent to Checkout read-only in gCvs)
> CVS Messages (equivalent to Quiet mode in gCvs)
> Prune empty directories
> Compression level
> Encrypt communication
> Checkout text files with Unix LF
> Disable splash screen
> Supply control when adding files
> Match path case with Entries case
> Logout automatically after N minutes
>
> Are these the ones you are referring to, or are you referring to
> everything in the Settings dialog?
>
> Regardless, I still like the idea of having Project setting inherit=20=20
> the
> global ones but allow for override.  But now having written all=20=20
> this, it
> sounds like a better name would be "Default settings" and then=20=20
> "Project
> settings".
>
> Some things seem truly global, like path to CVS executable, preferred
> external diff program.  Why would you want that to vary by project?
> Perhaps we need to revisit what is a global and what is per project.

As I mentioned above, the distinction between global and per-project=20=20
(or per-sandbox) settings is already there...

The other thing I was referring to were the 'local' settings: In=20=20
MacCvs, you can have more than one browser window open, each one=20=20
pointing to a different sandbox. However, the current settings=20=20
implementation uses global CPersistent instances to access the=20=20
settings. This means that theoretically, each of the browsers would=20=20
access the very same settings. The current solution in MacCvs is to=20=20
switch the settings when bringing another browser window to front,=20=20
i.e. store the modified settings of the browser/sandbox being=20=20
deactivated and load the settings for the browser becoming the front/=20
focused window. This is really a big hack, since if there was some=20=20
code that would read settings for a background window, this code=20=20
would suddenly get the settings for the other sandbox!
In order to solve this problem, I started once to make the=20=20
CPersistent values dynamically allocated and create a=20=20
CPersistentContainer that would encompass the set of persistent=20=20
values that comprise the sandbox settings. Then the browser would=20=20
keep a pointer to the CpersistentContainer object and ask this object=20=20
for specific settings. Essentially, it's pretty much making the=20=20
CvsPrefs class not a singleton, but allocated dynamically where each=20=20
instance keeps it's own set of settings (except for the global=20=20
settings, which are, of course, shared among all instances, to make=20=20
them - well - global ;-)

This involved quite a dose of code changes, since the settings object=20=20
needs to be passed around to anything that needs access to the=20=20
settings. There were also a couple of places left where I haven't yet=20=20
come up with a proper solution - like e.g. the timer code that=20=20
automatically logs out after a specified interval. This code is -=20=20
most likely - broken anyway on the Mac, since it assumes there is a=20=20
single cvs pserver we're connected to, but if you have multiple=20=20
browser windows open, chances are you are logged into more than one=20=20
server...

Anyway, the main issue here is that switching to a 'local settings'=20=20
model requires some major API changes to pass the settings around,=20=20
but it would also allow things like 'shoot and forget' style cvs=20=20
command handling, i.e. allow to kick off one cvs command and without=20=20
having to wait for this command to finish, immediately kick off the=20=20
next command. This may even be helpful for single browser=20=20
implementations, where you wouldn't have to wait for certain=20=20=20
commands to finish before launching the next command (e.g. update one=20=20
subdirectory, commit another one, etc.)

IMHO, the switch to 'local' settings is the more important step over=20=20
the switch to overridable settings and/or replacing the CPersistent=20=20
model. However, when breaking the APIs anyway, it would certainly be=20=20
a good time to adjust the persistent model as well.

Personally, my favorite settings implementation would really look=20=20
something like this:

class Settings
{
public:
	static Settings* CreateSettingsForPath(const char* sandboxPath);

	void Read();
	void Write();

	bool GetString(const char* key, std::string& value);
	void SetString(const char* key, const std::string& value);

	bool GetInt(const char* key, int& value);
	void SetInt(const char* key, int value);

	bool GetBool(const char* key, bool& value);
	void SetBool(const char* key, bool value);

	// ... more specific accessors could go here

	// this one allows to retrieve lists of [sub-]settings - this one=20=20
would allow to implement things like persistent string lists
	// (e.g. the list of previous CVSROOTs)
	bool GetArray(const char* key, std::vector<Settings>& valueArray);
	void SetArray(const char* key, const std::vector<Settings>&=20=20
valueArray);
};

We'd pass around a settings object and any code needing settings=20=20
would ask that settings object for the specific setting values.
The settings class is responsible for reading/writing settings in a=20=20
type-safe manner, i.e. it would check for proper values when reading=20=20
settings (which would also be platform specific to allow storing the=20=20
settings in a platform specific manner - PropertyList files on Mac=20=20
OS, perhaps Registry on Windows, ASCII files in ~/.gCvs/Settings/ on=20=20
Linux).

Alternatively, the accessor APIs could just return the value itself,=20=20
e.g.
	std::string GetString(const char* key);
If the settings value is not specified in the project settings, a=20=20
default value would be returned. Maybe that's even easier, although=20=20
it might be nice to have both APIs (in case you need to check for the=20=20
existence of certain settings). The second variant could then just=20=20
use the first one internally and provide the default value if the=20=20
first one returns false...

just my =80.02,
</jum>



=20
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
=20