Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Handling of configuration

<< < (2/4) > >>

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:

--- Quote from: tiwag on February 02, 2006, 05:58:56 pm ---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

--- End quote ---
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page