Handling of configuration

[takeshimiya]

Hi! There are some problems with the handling of the .conf.

The problem is that all the settings are read from there, but if C::B updates something (for example, let's say you have C::B RC3, and upgraded to RC4) like new keywords in an existing lexer, or compiler configuration, etc. everything is read from the .conf and ignores all the new things.

NOTE : we have another issue, even when this has been adjusted, it does not work immediately, since the default.conf still has the old one stated and overrules the code !!!!!! Very dangerous !!!

What to do in these cases? Merge the settings? The new C::B settings should override the user configuration? They should be ORified instead of XORified? There should appear a MessageBox to let the user decide?

[killerbot]

"settings set" version number in the conf and the sources, where on an upgrade some sort of merge happens. Challenge : what's to be considered a good merge ??

[Michael]

It would not be possible to delete the old and store the new one? A merge is oft error-prone and the errors are difficult to spot.

Michael

[killerbot]

It would not be possible to delete the old and store the new one? A merge is oft error-prone and the errors are difficult to spot.

Michael

damn right, but on the other hand, suppose you have several 'self registered' compilers, with for example all those regular expressions. You don't like to loose that. But for the compilers we can probably solve it in the future (a config file per compiler, with an unique ID).

[EDIT} but then when the user altered some built-in compiler settings, should we merge here then when we change something to the 'in house' settings for that compiler (like today, we changed something to the settings of Digital Marc C/C++ compiler (bug fix)).

[takeshimiya]

But there can be times that the user willn't want to loose the data.

Real example: In a patch applied yesterday, which adds keywords to the cpp_lexer.xml (for example try the keyword uint8_t), aren't loaded the new keywords, because all the keywords are being read from the .conf.

[Michael]

Ok, yes, right. The user probably would not really appreciate to loose her/his custom data (I know something about that . What it could help, at least on the syntax level would be to define an XML schema for the config file and use it to validate the config file after some merge occurred. Regarding the semantic level, things are more difficult. May be RDF could help.

Anyway, a good practice would be to save the original config before any merge, so in case something goes wrong, the user will not loose her/his data.

Michael
 

[tiwag]

i do it the following way,

1. backup your *.conf with your favorite-settings to another name i.e. backup.conf

2. start C::B and it generates a new default.conf with the actual settings

3. run a good merge program and merge your favorite-settings (like my compilers, display colors etc..)
   from your backup.conf into the default.conf file

[takeshimiya]

i do it the following way,

1. backup your *.conf with your favorite-settings to another name i.e. backup.conf

2. start C::B and it generates a new default.conf with the actual settings

3. run a good merge program and merge your favorite-settings (like my compilers, display colors etc..)
   from your backup.conf into the default.conf file

You can't expect all users will do (or know how to do) that.

I think that having two category settings can handle this:

-Items that can be OR'ed. In the example of the lexer's keywords, it is logical to merge the user settings with the C::B new settings.
-Items that should be XOR'ed. There are items that are mutually exclusive. Example: A configuration item that changed the behaviour for the good.

Altrough this doesn't cover the case when let's say, the user erased on purpose some keywords (ie. he/she doesn't likes to syntax highlight the keyword if).

Or maybe, another way could be some kind of version handling...

[takeshimiya]

Ok, I found a really better way.

SciTE handles this right.
The idea is that the configuration will be separated in 3 different files: global.conf, local.conf, and user.conf.

Where:
global.conf will contain all the settings that C::B uses, by factory default. The user can change them though, but when the user updates to the next C::B version, all the entire file will be replaced, so it's adviced to not change anything over that file.

user.conf will contain only the settings that the user override (change) in respect to the global.conf. Nothing less nothing more. The point is that it should not be a copy of global.conf, but instead only store the settings that differ.

local.conf is the same concept as user.conf, but it will be applied to the entire system (root privileges probably), not only the current user.

So user.conf overrides local.conf, and local.conf overrides global.conf.

[Michael]

And to have your three configurations in one XML file, instead of three different files? Updating it should be possible through XML processors and/or XSLT processors. IMHO using XML/XSLT is a clean way to go .

Michael

[thomas]

Ok, I found a really better way.

I am having a déjà vu of November 17, 2005...

[takeshimiya]

I am having a déjà vu of November 17, 2005...

Could it be because it's still flawed...? :wink:

[takeshimiya]

And to have your three configurations in one XML file, instead of three different files?

If the separation is logical, it should be physical (also it's more understandeable). The Local settings can't be on the same file (ie. probably only an user with admin privileges can change it).

[Michael]

The Local settings can't be on the same file (ie. probably only an user with admin privileges can change it).

Yes, in such a case you cannot use just one file. Anyway, the idea was to have an XML where root was e.g., Settings and its three (or more or less) children were Global, User and Local (may be this not). By using XML and XSLT processors you can then modify each child independently (or not, it depend on what you want to do . You can for example look at one MPEG-21 DIA works. From a bitstream a (generic) description (XML-based) is generated. This XML description is successively modified to fit particular constraints (could be modified several times, anyway). At the end the adapted bitstream is re-created from the transformed bistream. All this is possible by using XML/XSLT.

Michael

[takeshimiya]

I've never used XSLT transformations, and yes, it's possible, but it can complicate things where it's not necessary.