Author Topic: Where to store the configuration of Code::Blocks  (Read 27914 times)

takeshimiya

  • Guest
Where to store the configuration of Code::Blocks
« on: August 12, 2005, 10:15:56 pm »
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?

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Where to store the configuration of Code::Blocks
« Reply #1 on: August 12, 2005, 10:21:54 pm »
the best place for the INI File is in the same dir. as Code::Blocks

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #2 on: August 12, 2005, 10:40:03 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Where to store the configuration of Code::Blocks
« Reply #3 on: August 12, 2005, 10:58:06 pm »
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

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Where to store the configuration of Code::Blocks
« Reply #4 on: August 13, 2005, 12:04:05 am »
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #5 on: August 13, 2005, 12:33:00 am »
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? :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Where to store the configuration of Code::Blocks
« Reply #6 on: August 13, 2005, 01:37:11 am »
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 :P Maybe i could adapt it to read xml, too!

takeshimiya

  • Guest
Re: Where to store the configuration of Code::Blocks
« Reply #7 on: August 13, 2005, 04:20:57 am »
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?
« Last Edit: August 13, 2005, 04:26:13 am by takeshimiya »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #8 on: August 13, 2005, 12:05:08 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline squizzz

  • Almost regular
  • **
  • Posts: 132
Re: Where to store the configuration of Code::Blocks
« Reply #9 on: August 13, 2005, 12:46:42 pm »
Quote
Where will you prefer to store the configuration (in the Windows ver.)?
Definitely any external file (XML or .INI), rather than registry.

Quote
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. ;)
this space is for rent

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Where to store the configuration of Code::Blocks
« Reply #10 on: August 13, 2005, 01:37:41 pm »
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).

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #11 on: August 13, 2005, 02:13:33 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Where to store the configuration of Code::Blocks
« Reply #12 on: August 13, 2005, 03:51:52 pm »
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
« Last Edit: August 13, 2005, 03:56:43 pm by tiwag »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #13 on: August 13, 2005, 04:06:28 pm »
Now there is a really good idea :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Where to store the configuration of Code::Blocks
« Reply #14 on: August 13, 2005, 04:28:35 pm »
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? 8)

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)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #15 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?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Where to store the configuration of Code::Blocks
« Reply #16 on: August 13, 2005, 04:49:02 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?
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #17 on: August 13, 2005, 05:00:47 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Where to store the configuration of Code::Blocks
« Reply #18 on: August 13, 2005, 05:29:10 pm »
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

  • Guest
Re: Where to store the configuration of Code::Blocks
« Reply #19 on: August 13, 2005, 05:53:24 pm »
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

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #20 on: August 13, 2005, 06:14:42 pm »
...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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Where to store the configuration of Code::Blocks
« Reply #21 on: August 13, 2005, 08:25:50 pm »
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 '.').

Quote
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).

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #22 on: August 19, 2005, 01:21:22 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Where to store the configuration of Code::Blocks
« Reply #23 on: August 19, 2005, 03:22:46 pm »
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 8).

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #24 on: August 19, 2005, 04:18:02 pm »
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).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline AkiraDev

  • Multiple posting newcomer
  • *
  • Posts: 71
Re: Where to store the configuration of Code::Blocks
« Reply #25 on: August 19, 2005, 04:38:21 pm »
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.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Where to store the configuration of Code::Blocks
« Reply #26 on: August 19, 2005, 05:50:40 pm »
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

  • Guest
Re: Where to store the configuration of Code::Blocks
« Reply #27 on: August 19, 2005, 11:44:13 pm »
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?

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Where to store the configuration of Code::Blocks
« Reply #28 on: August 20, 2005, 05:13:59 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

sushi_cw

  • Guest
Re: Where to store the configuration of Code::Blocks
« Reply #29 on: August 30, 2005, 07:39:42 pm »
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.

takeshimiya

  • Guest
Re: Where to store the configuration of Code::Blocks
« Reply #30 on: September 10, 2005, 01:01:32 pm »
For me the most practical way seems to be:

-Search first for %PATH_FROM_WHERE_CODEBLOCKS_IS_RUNNING%/codeblocks.ini
-If not found in the above (almost all times), search for it in %APPDATA%/codeblocks/codeblocks.ini

The default and prefered way would be %APPDATA%/codeblocks/codeblocks.ini
The first way can be used for example, when running C::B from a USB key, or when using multiple installations of C::B with different configurations

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Where to store the configuration of Code::Blocks
« Reply #31 on: September 10, 2005, 06:07:17 pm »
Yeah, I like that :-)

Offline tuft

  • Single posting newcomer
  • *
  • Posts: 9
Re: Where to store the configuration of Code::Blocks
« Reply #32 on: October 28, 2005, 08:14:30 pm »
Where is the configuration stored for now? I cannot find any codeblocks.ini anywhere.