Never heard of it. wxWidgets wxFileConf is actually documented, and you can read and write to it with only two statement. It works very well.
It's sad you never heard of it, since it's used everywhere all over the application, and in all plugins (except the two above), and it's the recommended canonical way of saving user configuration. It is neither complicated, nor secret magic. And it's very convenient for complex datatypes that wxFileConfig does not support at all, too.
As far as documentation is concerned, I almost never document any of my code because I think if someone needs to read a manual to know what to do with a class, then the guy who wrote it in the first place has not done a particularly good job.
Also, the wxWidgets documentation is so blatantly wrong in some places that they had better written none at all. I don't know about the particular case of wxFileConfig, though.
Nevertheless, ConfigManager class is quite well documented (well... for my measures, anyway). Not like a function as
void Write(const wxString& name, int value); needs an awful lot of documentation, anyway
And I dont have to home brew all the xml calls and deal with the crashed, corrupted .conf files.
You don't use one single XML call using the configmanager. I'm surprised where you get that idea from.
Corrupted
.conf files are something that happened a long time ago, partly because of implementation details from my side (insufficient user input error checking), but also from literal abuse (using user-entered strings as key names, and entering Chinese strings).
Most (hopefully all?) things you can do wrong should be caught by now, and there is no real recent issue regarding the config manager that I know of.
Clearly, ConfigManager works after the same principle like all software does at its core: shit in = shit out.
There is sure some way you can corrupt the config file, one way or the other. However, show me one piece of software which does not have that property.
All in all, "having to deal with crashed, corrupted .conf files" is a most unfair statement, given the fact that not few of the past crashes actually came from KeyBinder, and
.conf files are saved a lot more reliably than anything in wxWidgets (because the often-used "safe"
wxTempFile class is not safe at all). Yes, file corruption may occur, in any file, with any program, for whatever reason... that's an implementation detail of what we commonly call "reality". But I don't like it when people make it sound like ".conf files are corrupted all the time", because that's simply not true.
I don't get it. Why can't CB just tell us where it's reading and writing the config from/to. That's all we need to know.
Apart from the fact Yiannis said "no", which concludes that subject, I'm not bothered about that if you believe that it absolutely has to be. It's not a state secret and we don't have to kill you if we tell you. However, it would not solve your problems!
To give an example why it won't help: Are you aware of the fact that Code::Blocks can be given a profile URL and will transparently read its configuration from a
http:// URL?
We do not currently support WebDAV, so saving remote configuration does not work yet, but that is something which will be added in the future (in fact, it'll be anything supported by libcurl).
The idea behind that is that it does not matter where on your PC or where on this planet (or any place in the universe?) Code::Blocks is located and where the configuration is placed. As long as the internet has a route to it, things will just work. You don't need to know why or how, and you don't want to know.
If you implement your own config saving using whatever other library, you will have to take care of this, too.
Now please don't tell me about
wxFileConfig reading from and writing to URLs via
wxFileSystem... I'll fall off my chair otherwise.
