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

Where to store the configuration of Code::Blocks

<< < (5/7) > >>

thomas:

--- Quote from: Urxae on August 13, 2005, 05:29:10 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.
--- End quote ---
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:

--- Quote from: takeshimiya 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.

--- End quote ---

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:


--- Quote from: thomas on August 13, 2005, 06:14:42 pm ---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.

--- End quote ---

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.

--- End quote ---

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:

--- Quote from: thomas 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.

--- End quote ---
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).

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page