Where to store the configuration of Code::Blocks

[takeshimiya]

Where will you prefer to store the configuration (in the Windows ver.)?

If you vote for the INI File, where will be the best place for it?
In the same dir. as Code::Blocks? In the Documents and Settings of the current windows user?

[tiwag]

the best place for the INI File is in the same dir. as Code::Blocks

[thomas]

Accounting for the fact that code::blocks comes with tinyxml and does its project files in xml, I'd prefer an xml file, both for consistency, and for "coolness". It would be cross-platform and backwards-compatible, too.
Since there is no choice for that, the vote is .ini file.

[tiwag]

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

[rickg22]

No, wait...

Can I take my vote back? I just realized  that if the path used is the same path to the executable, you can't run Code::Blocks from a CD or a readonly device.

[thomas]

What about something like %APPDATA%/codeblocks/codeblocks.ini on Windows and something like ~/.codeblocks under Linux? That would be the way every "good" application is doing it.

Speaking of taking back votes... could we have an option to vote for "xml", too?

[rickg22]

I'd say xml is a must. Heck, I DO have a class for writing data into native XML! :shock:
I had written it for my job Maybe i could adapt it to read xml, too!

[takeshimiya]

Haha, I was about to put an XML option, I want something different to the Registry right now! Because wxConfig INI's backend is already implemented. It's a one-line change to support INI files.

But the best way to handle an XML configuration file is already in the wxWidgets roadmap:  :wink:

http://www.wxwidgets.org/roadmap.htm
-Write wxConfig implementation using XML as backend:
    * Portable wxXMLConfig for all platforms

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 (I don't think it would be difficult).
And then you can contribute it to the wxWidgets code itself.

Anyone?

[thomas]

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

But... but... but... we already have tinyxml packaged with code::blocks!

Tinyxml can read and write xml, and it is quite easy to use, and platform independent. Tinyxml works reliably and is reasonably efficient.

[squizzz]

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?
In the same dir. as Code::Blocks? In the Documents and Settings of the current windows user?

I'd love to have it in the same dir as C::B, but this solution has some downsides, like rick22 mentioned.
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.

[Urxae]

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?
I suppose if you drop the "any other dir" and just allow %APPDATA%/codeblocks and the installation directory you can look for it in those locations (preferably in that order, so if one user wants different settings from any system-wide ones he can have C::B create one in his %APPDATA% folder).

[thomas]

Letting the user place the config files may be disadvantageous (and Urxae is right... where to store that info, in the registry? )

%APPDATA% is really the place that is designated for that purpose under Windows, it works like a charm, too.
When I lately got a new PC, I just copied the Thunderbird and Firefox folders from %APPDATA% over the network, and I had all my email and all my settings on the new PC. That is really how software should work
I wish Office worked that way, too!

Under Linux, I think that ~/.bash_profile, ~/.fetchmailrc, ~/.gnome, ~/.ssh, or ~/.mozilla are good examples for a scheme that works and that each user is able to understand.

[tiwag]

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

[update]
more clearly spoken:
if there is no overruling commandline option which tells codeblocks to use a specific codeblocks.ini it should use the standard %APPDATA%/codeblocks/codeblocks.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

[thomas]

Now there is a really good idea

[Urxae]

if there is no overruling commandline option which tells codeblocks to use a specific codeblocks.ini it should use the standard %APPDATA%/codeblocks/codeblocks.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

Yes 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 .

Another idea is to do the above, and if no command line option is given and the appdata file isn't found (ie. this is the first time this user starts C::B), look for a settings file in the C::B directory and copy it to the appdata location. That way, if some [company/group] wants to use certain coding standards that deviate from the default C::B options, it can provide its own default options [on disk images/in custom installers/as a separate download]. Doesn't hurt to be optimistic, does it?

Oh, and I think %APPDATA%/codeblocks/codeblocks.[ini/xml] isn't the best filename, it's a bit redundant. %APPDATA%/codeblocks/settings.[ini/xml] is much better, I think. (and ~/.codeblocks/settings.[ini/xml] on Linux, of course)