Where to store the configuration of Code::Blocks

[thomas]

Since we're talking about one single file, one might just leave the folder away.
Or are there any other files (except the per-project files like layout etc.) that need to be stored somewhere?

[Urxae]

Since we're talking about one single file, one might just leave the folder away.
Or are there any other files (except the per-project files like layout etc.) that need to be stored somewhere?

It never hurts to store plugin settings in there too, so those could be put in that directory too (or in subdirectory by name of plugin, or plugins/<name>). And I'm not sure how personalities are handled, but I think separate files would be in order there.

[thomas]

Plugin settings are stored inside the main configuration file. That's what all of them do right now, and I think it is a good idea.

Personalities can very easily be implemented in xml,  just stuff everything into a <personality name=""> tag. The question is if you need explicit personalities at all, however.
Remember that if you move away from HKEY_LOCAL_MACHINE to a file stored in %APPDATA%, then you have implicit personalities, one per username. So for two users on the same PC, you would just have two accounts.

[Urxae]

Yes, you could theoretically stuff anything you want in an XML file (binary data even, though I'm not sure if tinyxml supports that), but do you want to?
What if someone wants to copy a subset of the settings to another computer? It might just be drag-and-drop a single XML file if they're separate, instead of copy-pasting bits of monolithic.xml.
In my coding standards example above, but after everyone installed C::B on their own: Editor & AStyle settings are probably the only things that have to be copied. In fact, if you copy the compiler settings as well that might be a problem if the paths differ on those machines.

And yes, different personalities might very well come in handy for the same user. For example, suppose C::B at some point actually supports other languages (as in plugins have been written for compiler, codecompletion, etc.) , then a user might have one personality per language each with the correct plugins enabled for that language. That way, the C++ codecompletion doesn't try to parse Python files, you don't have to switch to another compiler each time you switch languages (just click the shortcut named "CodeBlocks - $LANGUAGE" you created) - that kind of stuff.
It's not really practical to have one user for C++ and one for Python, even though it might work . (Yes, with some set up you could enable "run as" in the shortcuts. No, that still isn't practical)

[takeshimiya]

I think the one file approach is good, because if you want only the settings of Editor & AStyle, you can actually do that using Settings->Import/export configuration.
And in fact, the file exported by that function should have the subset of options you must choose of the configuration file. It'll be a stripped configuration file then.

Regarding XML, you can use tinyXML but you must make and implement a class of wxXMLConfig (as a backend to wxConfig) because C::B currently uses wxConfig (which), so to support wxXMLConfig should be a one-line change also.

Indeed, even the user could choose in what format and where to store the config. file using command line, something like:

Code

#codeblocks --config-type=registry
or
#codeblocks --config-type=xml --config-path=%APPDATA%
or
#codeblocks --config-type=ini --config-path=C:\Dev\CodeBlocks

[thomas]

...a user might have one personality per language each with the correct plugins enabled for that language. That way, the C++ codecompletion doesn't try to parse Python files, you don't have to switch to another compiler each time you switch languages (just click the shortcut named "CodeBlocks - $LANGUAGE" you created) - that kind of stuff.

Umm... don't know if that is really practical, either. It should be possible to tell which compiler or which syntax parser to use from a file's type. Personally, I perceive having to create separate personalities for different languages as quite a turn-off feature.
There are very well editors and IDEs out there which can correctly syntax-style 30 or 40 different file types, and the user can plug in as many styles as he likes in a snap. It would be quite poor if code::blocks would not come up with an equal solution.

Anyway, if separate personalities are really a "must" (maybe for another reason), then one could simply put these into separate files (config.xml, config.onepersonality.xml, config.anotherpersonality.xml) to somehow reduce the amount of parsing necessary. Also, one could easily add/remove/copy individual personalities this way or derive from an existing one.
Plugin settings, however, should still reside inside the respective "main" file, since that way you can have per-personality plugin settings. Otherwise, you would need to keep track of that inside dozens of individual files, which is a horrible mess.

[Urxae]

I think the one file approach is good, because if you want only the settings of Editor & AStyle, you can actually do that using Settings->Import/export configuration.
And in fact, the file exported by that function should have the subset of options you must choose of the configuration file. It'll be a stripped configuration file then.

Right, forgot about that option. Does it work yet? Last I checked you could export settings, but not actually import them (hadn't been implemented yet). And IIRC even exporting had problems... :shock:

Umm... don't know if that is really practical, either. It should be possible to tell which compiler or which syntax parser to use from a file's type. Personally, I perceive having to create separate personalities for different languages as quite a turn-off feature.
There are very well editors and IDEs out there which can correctly syntax-style 30 or 40 different file types, and the user can plug in as many styles as he likes in a snap. It would be quite poor if code::blocks would not come up with an equal solution.

Actually, now that I think about it, I think it already does that. However, this means it doesn't recognize the standard headers (<string>, <vector>, etc.) as those have no extension . I'm not sure how this will be fixed, but it might change this behavior. IIRC, the Eclipse C/C++ plugin just has the standard headers hardcoded as "parse these too" :? (actually, it has them registered as C++ extensions, and it defines extension as the part after the last '/' or '.').

Anyway, if separate personalities are really a "must" (maybe for another reason), then one could simply put these into separate files (config.xml, config.onepersonality.xml, config.anotherpersonality.xml) to somehow reduce the amount of parsing necessary. Also, one could easily add/remove/copy individual personalities this way or derive from an existing one.
Plugin settings, however, should still reside inside the respective "main" file, since that way you can have per-personality plugin settings. Otherwise, you would need to keep track of that inside dozens of individual files, which is a horrible mess.

Alright, assuming import and export functionality works (or will work before 1.0), I'll give you this one.

However at least one of my points still stands: Code::Blocks should have its own settings directory (not file) in %APPDATA%/CodeBlocks (Windows) and ~/.codeblocks (Linux) . Besides, this is also better just in case other types of files will be stored there in the future.
And I think C::B already has a folder in %HOME%/.CodeBlocks where it stores workspaces. Maybe those should be migrated to %APPDATA%/CodeBlocks or the settings stored in %HOME%/.CodeBlocks (the latter is better for backwards compatibility perhaps, but I see no other reason to do that besides being consistent with the Linux version. We're currently still in beta, so right now I think it can still be changed without too many problems).

[thomas]

Uh... did it not occur to anyone that changing the config manager on an existing project (unless you use a pluggable builtin) is a really stupid idea, lol.
It did not occur to me when I said "hey, we should use xml", but it does now, trying to actually do it.
Ah well, lets see where I get until after the weekend.

[Urxae]

Uh... did it not occur to anyone that changing the config manager on an existing project (unless you use a pluggable builtin) is a really stupid idea, lol.
It did not occur to me when I said "hey, we should use xml", but it does now, trying to actually do it.
Ah well, lets see where I get until after the weekend.

Well, when a few betas back the project file format (I think) was changed in a non-backwards compatible way, code was added to detect if it was in the old format and correctly loaded that. Then when you saved your project again it was automatically saved in the new format.
Maybe you can do something similar: If no XML settings file is found, check the old-style settings (registry or ~/.codeblocks depending on OS). Or maybe check that first?. Anyway, if the settings are found there, load them and save them to XML (and possibly delete from the old location, especially if that's checked first). Automagic conversion .

[thomas]

Oh, if it were only that. This is not even the point I was complaining about. It is rather the fact that everybody used all these polymorphic funcitons that come with wxConfigBase without bothering (well, honestly why would they bother, too? Of course you use functions that are available!).
So consequently, to even replicate the original functionality, you have to implement  42 (forty-two) special cases of accessor functions in your class if you are not inclined to rewrite the major part of code::blocks.

It would be still a lot worse if I actually derived from wxConfigBase (which I don't), because then I would have to implement every pure virtual function, no matter how useless. Yes, it is true that deriving from wxConfigBase would require no changes in the other files at all. But apart from being still more work, there are another few good reasons not to do it.

The only thing that really needs wxConfigBase is the recently used files list, and I am happy to write a workaround for that (add items from a wxArrayString instead of calling Load()). Everything else compiles fine if you replace wxConfigBase with ConfigManager (the new version) globally. That way, ConfigManager handles the xml stuff itself (without yet another level of indirection), and is not limited by the design of wxConfigBase, so for example per-module namespaces can be used, and non-primitive types like wxArrayStrings can be stored/retrieved with one query rather than walking through the config by hand. Or you can do whatever magic you want with a dozen config files. You can of course still do that if you derive from wxConfigBase, but then you break its design which is very bad. If you use wxConfig, then consequently the access method (INI or xml, or registry) must not matter. Hence you cannot introduce new functions that don't exist in the other implementations.
Also, without wxConfigBase, you can more-or-less replace wxString with std::string and use the very same code in a non-wxWidgets project, which is an advantage, too (there is a little more work due to wxArrayString, but you got the idea).

[AkiraDev]

Hmmm...

Just HOW complicated exactly (= how many hours work) would it be to make a specialization of wxConfigBase to a new wxXMLConfig class?

Were that the case, it would be fairly simple to preserve a lot of Code::Blocks code.

EDIT: OK, I got your point in the last paragraph of your post, nevermind.

[rickg22]

I think it would be wiser to keep the current model until all the pros and cons are discussed (this is, _AFTER_ 1.0).

Something very important: If it ain't broke, don't fix it!

The config manager has been the only module that hasn't given us trouble in the past (with the exception, of course, of those cases where HOME=%USERPROFILE%, but I'm sure that can be fixed somehow). I'm happy as it is.

[takeshimiya]

Ok, I can suppose then that BEFORE C::B 1.0 we can have the configuration stored in INI files. 
And AFTER C::B 1.0 we can do the XML configuration stuff, right?

[thomas]

That is a one-line code change, sounds like a good idea.

I will play with it anyway, and if it turns out to be stable before 1.0 and if it finds unanimous acceptance, you can still incorporate it, should not need too many changes really.

[sushi_cw]

I don't care if it's INF, XML or whatever, just not the registry. Putting everything in %appdata%/codeblocks seems like a perfect idea to me.