User forums > General (but related to Code::Blocks)

Where to store the configuration of Code::Blocks

<< < (4/7) > >>

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:

--- Quote from: thomas on August 13, 2005, 04:40:44 pm ---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?

--- End quote ---
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 :P. (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
--- End code ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page