Accounting for the fact that code::blocks comes with tinyxml and does its project files in xml, I'd prefer an xml file...i agree, second that
http://www.wxwidgets.org/roadmap.htm
[...]
It's on the roadmap, so it will be implemented at some time, but of course, if you want wxXMLConfig right now, you must implement yourself
Where will you prefer to store the configuration (in the Windows ver.)?Definitely any external file (XML or .INI), rather than registry.
If you vote for the INI File, where will be the best place for it?I'd love to have it in the same dir as C::B, but this solution has some downsides, like rick22 mentioned.
In the same dir. as Code::Blocks? In the Documents and Settings of the current windows user?
I think I vote for Thomas' "something like %APPDATA%/codeblocks/codeblocks.ini on Windows and something like ~/.codeblocks under Linux" as default setting, with user's ability to change it to any other dir at Settings->Environment. ;)So you want to make it a setting where to store the settings? Where would you store that setting then?
Where would you store that setting then?...it could be a commandline option which overrules the standard %APPDATA%/codeblocks/codeblocks.ini on Windows when it's given
if there is no overruling commandline option which tells codeblocks to use a specific codeblocks.ini it should use the standard %APPDATA%/codeblocks/codeblocks.iniYes of course that works, but I was replying to squizzz suggesting it should be an option under Settings->Environment which doesn't. This is indeed probably the best solution, provided you substitute .xml for .ini ;).
so for testing and temporary configurations one can use a specific config.ini by using that commandline option, while the user-specific config.ini is used normally
Since we're talking about one single file, one might just leave the folder away.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.
Or are there any other files (except the per-project files like layout etc.) that need to be stored somewhere?
#codeblocks --config-type=registry
or
#codeblocks --config-type=xml --config-path=%APPDATA%
or
#codeblocks --config-type=ini --config-path=C:\Dev\CodeBlocks
...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.
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.
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.
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.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.
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.