User forums > General (but related to Code::Blocks)
"Portable" Code::blocks?
stahta01:
--- Quote from: thomas on February 07, 2007, 03:34:11 pm ---Anyway, if it absolutely has to be, we can add something like GetActiveConfigfilesFolder(). I don't think it is any good, because it solves one problem while opening another at the same time, but if that's what everybody wants, then so be it.
--- End quote ---
How about adding a startup parameter that means saves all configs in the executable folder.
If you pick the parameter I can work on a patch for it.
Tim S
Pecan:
--- Quote from: thomas on February 07, 2007, 03:34:11 pm ---The config manager was written to allow you to save and restore your settings with one line of code (such as ConfigManager::Get(_T("dragscroll"))->Write(_T("enable"), m_enable); ) without needing to bother about such annoying things as files and paths, serialising/unserialising data, removable media, and installations.
--- End quote ---
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.
--- Quote from: thomas on February 07, 2007, 03:34:11 pm ---You are expected to write your configurations to the config file, not to brew your own.
However, if you do your own thing, that's fine, but then you have to do all the nasty work for portability, too...
--- End quote ---
I didn't brew my own. I called wxWidgets. And I dont have to home brew all the xml calls and deal with the crashed, corrupted .conf files.
--- Quote from: thomas on February 07, 2007, 03:34:11 pm ---Anyway, if it absolutely has to be, we can add something like GetActiveConfigfilesFolder(). I don't think it is any good, because it solves one problem while opening another at the same time, but if that's what everybody wants, then so be it.
--- End quote ---
Finally. Thank you.
mandrav:
--- Quote from: thomas ---If reading that config that fails, the program will attempt read the config from the program's location (possibly on CDROM or an USB stick), and write it back onto that medium if allowed to do so (failure, as on CDROMs or write-protected media, will be silently ignored). This is is exactly what you would want, too... you would not want to install or possibly overwrite any files on someone else's computer just because you happen to plug in a USB stick with Code::Blocks on it!
--- End quote ---
Thanks for clarifying.
People, this is the correct behaviour from our point of view. The only extra thing I would possibly agree to add, is a special command line option to make it always use the config in the app folder.
Pecan:
--- Quote from: mandrav on February 07, 2007, 04:08:34 pm ---
--- Quote from: thomas ---If reading that config that fails, the program will attempt read the config from the program's location (possibly on CDROM or an USB stick), and write it back onto that medium if allowed to do so (failure, as on CDROMs or write-protected media, will be silently ignored). This is is exactly what you would want, too... you would not want to install or possibly overwrite any files on someone else's computer just because you happen to plug in a USB stick with Code::Blocks on it!
--- End quote ---
Thanks for clarifying.
People, this is the correct behaviour from our point of view. The only extra thing I would possibly agree to add, is a special command line option to make it always use the config in the app folder.
--- End quote ---
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.
wxLearner:
--- Quote from: mandrav ---People, this is the correct behaviour from our point of view.
--- End quote ---
That's very good and is also a reason, why there should be an interface for plugin writers to use "the Code::Blocks logic" to get the currently used config folder.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version