Am I in position to request?
A version of code::blocks that:
- uses ini files in its folder instead of windows registry.
- allows relative path for compiler (root letter independant)
Err, that's about it, I currently use the normal code::blocks in my USB disk and it is quite great to be able to continue development on other comps, you get a lot more coding time (and we all love coding time) but it gets old to always set up compiler and that syntax highlighting is always the same with gray comments and things you would wish to change but know that changing them would not help you the next time..
Am I in position to request?
A version of code::blocks that:
- uses ini files in its folder instead of windows registry.
- allows relative path for compiler (root letter independant)
Err, that's about it, I currently use the normal code::blocks in my USB disk and it is quite great to be able to continue development on other comps, you get a lot more coding time (and we all love coding time) but it gets old to always set up compiler and that syntax highlighting is always the same with gray comments and things you would wish to change but know that changing them would not help you the next time..
I don't think CB uses the windows registry except in the older RC2 version
Hi !QuoteI don't think CB uses the windows registry except in the older RC2 version
Yes but configuration files are stored in the user profile (maybe all users ?).
Could it be possible to have the choice to store configuration in profile or in C::B install directory ?
Dje
Hi !QuoteI don't think CB uses the windows registry except in the older RC2 version
Yes but configuration files are stored in the user profile (maybe all users ?).
Could it be possible to have the choice to store configuration in profile or in C::B install directory ?
Dje
That's the default behaviour. Just move default.conf from the user profile dir to the codeblocks dir and it will use that instead the next time you launch it.
<rant>Why does nobody use the forum search???</rant>
<rant>Why does nobody use the forum search???</rant>
<rant>Why does nobody use the forum search???</rant>
Because it's an awful implementation of search. It seems to come up with nothing or everything. The user can't use special characters, and words can't be grouped and {insert more complaints}...
Yes, that will work after you apply my patch, if my patch is NOT applied please turn off the two plugins that don't work that way. They are mentioned at the end of the thread I linked to above.I looked at that patch a week or two ago (don't remember when exactly) and I'm reluctant to apply it because:
ad (1.): Code::Blocks confirmedly works fine from an USB stick. There are two third-party plugins (KeyBinder and DragScroll) which don't work properly, but that is because they do their own configuration saving.
In the particular case of KeyBinder, it may be hard to do differently (as it uses a wxCode class that does its own tampering and may not make custom saving easy at all).
However, for DragScroll, I see no reason why it cannot simply use the standard configuration system, which works fine.
A third-party plugin that does its own independent config handling should first look in the "correct" place, too, and should then fall back to locations like the executable's path, if not successful.
The reasoning behind this is to allow you to put Code::Blocks onto a CDROM (with customised settings, if wanted) and run it, but still be able to save individual settings on the client PC. The local user's settings folder on the hard disk is always the primary "correct" location for settings, as it is alterable.
We check C::B's location on startup (windows only) and if it's on a removable drive and we have read/write access, we use the same folder as the config folder. In all other cases we use the user's home folder. I think this should cover all parties...Not to try to teach my grandmother to suck eggs or anything, but why not:
Yes, that will work after you apply my patch, if my patch is NOT applied please turn off the two plugins that don't work that way. They are mentioned at the end of the thread I linked to above.I looked at that patch a week or two ago (don't remember when exactly) and I'm reluctant to apply it because:
1. I don't understand what that patch is about
2. it changes the semantics of GetConfigFolder()
3. it makes relocation dependent on using a special hardcoded profile name ("portable"), which I don't understand... it works without a special name now, too
ad (1.): Code::Blocks confirmedly works fine from an USB stick. There are two third-party plugins (KeyBinder and DragScroll) which don't work properly, but that is because they do their own configuration saving.
In the particular case of KeyBinder, it may be hard to do differently (as it uses a wxCode class that does its own tampering and may not make custom saving easy at all).
However, for DragScroll, I see no reason why it cannot simply use the standard configuration system, which works fine.
ad (2.): Your patch changes GetConfigFolder() to "location where configuration was loaded from", which is not what it is. GetConfigFolder() is "location where Code::Blocks expects its configuration (under normal circumstances)". That is, it's the place where it looks before searching exotic places such as the executable's folder.
The reasoning behind this is to allow you to put Code::Blocks onto a CDROM (with customised settings, if wanted) and run it, but still be able to save individual settings on the client PC. The local user's settings folder on the hard disk is always the primary "correct" location for settings, as it is alterable.
The idea is comparable to how "Yield" signs and traffic lights work. In "normal operation", you will stop or drive according to the traffic light, and only if that fails, you will (hopefully) stop at the "Yield" sign.
A third-party plugin that does its own independent config handling should first look in the "correct" place, too, and should then fall back to locations like the executable's path, if not successful.
@Thomas: how about this:Hmm... sounds like a lot of mischief... how to figure out if a drive is removable? And it should still work regardless of whether or not we have write access.
We check C::B's location on startup (windows only) and if it's on a removable drive and we have read/write access, we use the same folder as the config folder. In all other cases we use the user's home folder. I think this should cover all parties...
It looks like keybinder and dragscroll will have to de-couple from the sdk even more and start searching the directories themselves. Oh well....Why does dragscroll have to write config files at all? I understand that wxKeyBinder is a nasty bit of software, so ok... granted on that one. But what is in the dragscroll plugin that cannot be stored in the normal configuration file? I just don't get it, sorry :)
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.
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.
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...
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.
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!
Quote from: thomasIf 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!
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.
People, this is the correct behaviour from our point of view.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.
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.
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.
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!
[quote author=thomas link=topic=5115.msg40099#msg40099 date=1170866901]
[quote author=Pecan link=topic=5115.msg40088#msg40088 date=1170860317]
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]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 [tt]void Write(const wxString& name, int value);[/tt] needs an awful lot of documentation, anyway :)
[quote]And I dont have to home brew all the xml calls and deal with the crashed, corrupted .conf files.[/quote]You don't use one single XML call using the configmanager. I'm surprised where you get that idea from.
Corrupted [tt].conf[/tt] 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 [tt].conf[/tt] files are saved a lot more reliably than anything in wxWidgets (because the often-used "safe" [tt]wxTempFile [/tt]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.
[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.[/quote]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 [tt]http://[/tt] 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 [tt]wxFileConfig [/tt]reading from and writing to URLs via [tt]wxFileSystem[/tt]... I'll fall off my chair otherwise. :)
[/quote]
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?
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) set args --profile=http://ajonsson.kapsi.fi/default.conf
(gdb) run
Starting program: /usr/local/bin/codeblocks --profile=http://ajonsson.kapsi.fi/default.conf
[Thread debugging using libthread_db enabled]
[New Thread -1230850384 (LWP 22439)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1230850384 (LWP 22439)]
0xb723bb8c in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb723bb8c in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb723d83f in malloc () from /lib/tls/i686/cmov/libc.so.6
#2 0xb73ec4b7 in operator new () from /usr/lib/libstdc++.so.6
#3 0xb76374c9 in wxMutex::wxMutex () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#4 0xb7b7f735 in CfgMgrBldr (this=0xa53a768)
at /usr/local/include/wx-2.6/wx/thread.h:273
#5 0xb7b7fff6 in CfgMgrBldr::GetConfigManager (name_space=@0xbf3c1258)
at manager.h:144
#6 0xb7bee4bd in Manager::GetConfigManager (this=0xb7ef0460,
name_space=@0xbf3c1258) at manager.cpp:286
#7 0xb7b7dc3d in ConfigManager::GetProxy () at configmanager.cpp:443
#8 0xb7b7f2c3 in CfgMgrBldr::SwitchToR (this=0xa539e48,
absFileName=@0xbf3c13d0) at configmanager.cpp:281
#9 0xb7b7fa2d in CfgMgrBldr (this=0xa539e48) at configmanager.cpp:168
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1230084432 (LWP 22567)]
0xb72f87c6 in malloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb72f87c6 in malloc () from /lib/tls/i686/cmov/libc.so.6
#1 0xb76b93c9 in wxStringBase::Alloc ()
from /usr/local/lib/libwx_gtk2u-2.6.so.0
#2 0xb76b99b0 in wxStringBase::append ()
from /usr/local/lib/libwx_gtk2u-2.6.so.0
#3 0xb76c1641 in wxURI::ParseScheme ()
from /usr/local/lib/libwx_gtk2u-2.6.so.0
#4 0xb76c22e5 in wxURI::Parse () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#5 0xb76c236a in wxURI::Create () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#6 0xb76c44a7 in wxURI::wxURI () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#7 0xb771398c in wxURL::wxURL () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#8 0xb7c3a2bb in CfgMgrBldr::SwitchToR (this=0xa5414e8,
absFileName=@0xbf54f290) at configmanager.cpp:280
#9 0xb7c3aa2d in CfgMgrBldr (this=0xa5414e8) at configmanager.cpp:168
#10 0xb7c3aff6 in CfgMgrBldr::GetConfigManager (name_space=@0xbf54f328)
at manager.h:144
#11 0xb7ca94bd in Manager::GetConfigManager (this=0xb7fab460,
name_space=@0xbf54f328) at manager.cpp:286
#12 0xb7c38c3d in ConfigManager::GetProxy () at configmanager.cpp:443
#13 0xb7c3a2c3 in CfgMgrBldr::SwitchToR (this=0xa540bc8,
absFileName=@0xbf54f4a0) at configmanager.cpp:281
#14 0xb7c3aa2d in CfgMgrBldr (this=0xa540bc8) at configmanager.cpp:168
#15 0xb7c3aff6 in CfgMgrBldr::GetConfigManager (name_space=@0xbf54f538)
Way over complicated and unuseful.
Way over complicated and unuseful.
Why are you so hostile? Its actually a pretty elegant system. You access data with file system like paths and you don't have to worry about whether you have actually written the config data of not and non-intrusively handles complex data types.
I no longer care to write code tightly coupled to the CB sdk. When the day comes that it's more dependable and stable, I may change my mind.
QuoteI no longer care to write code tightly coupled to the CB sdk. When the day comes that it's more dependable and stable, I may change my mind.
We 're not going to change the sdk for no reason. If you "don't care writing code" with the sdk, there's nothing more we can do.
When "you change your mind", we can discuss this again...
Index: src/plugins/contrib/keybinder/cbkeybinder.cpp
===================================================================
--- src/plugins/contrib/keybinder/cbkeybinder.cpp (revision 3586)
+++ src/plugins/contrib/keybinder/cbkeybinder.cpp (working copy)
@@ -220,7 +220,10 @@
// Create filename like cbKeyBinder{pluginversion}.ini
//memorize the key file name as {%HOME%}\cbKeyBinder+{ver}.ini
- m_sKeyFilename = ConfigManager::GetConfigFolder();
+ if (ConfigManager::relo)
+ m_sKeyFilename = ::DetermineExecutablePath();
+ else
+ m_sKeyFilename = ConfigManager::GetConfigFolder();
//*bug* GTK GetConfigFolder is returning double "//?, eg, "/home/pecan//.codeblocks"
LOGIT(_T("GetConfigFolder() is returning [%s]"), m_sKeyFilename.GetData());
Pecan:
I think this will fix keybinder, I have not tested it.
Note, it will still not work if the executable is on a no write media like CD-ROM.
Tim SCodeIndex: src/plugins/contrib/keybinder/cbkeybinder.cpp
===================================================================
--- src/plugins/contrib/keybinder/cbkeybinder.cpp (revision 3586)
+++ src/plugins/contrib/keybinder/cbkeybinder.cpp (working copy)
@@ -220,7 +220,10 @@
// Create filename like cbKeyBinder{pluginversion}.ini
//memorize the key file name as {%HOME%}\cbKeyBinder+{ver}.ini
- m_sKeyFilename = ConfigManager::GetConfigFolder();
+ if (ConfigManager::relo)
+ m_sKeyFilename = ::DetermineExecutablePath();
+ else
+ m_sKeyFilename = ConfigManager::GetConfigFolder();
//*bug* GTK GetConfigFolder is returning double "//?, eg, "/home/pecan//.codeblocks"
LOGIT(_T("GetConfigFolder() is returning [%s]"), m_sKeyFilename.GetData());
I think this will fix keybinder, I have not tested it.Don't think you can compile that, because you access a private member from a non-friend class. Even if the compiler lets you do that (maybe with -fno-access-control), then you still obviously shouldn't, it's evil... ;)
Note, it will still not work if the executable is on a no write media like CD-ROM.
It looks like Pecan is not the onlyone, who misinterpreted "ConfigManager::GetFolder"...Code// Load the snippets
m_SnippetsTreeCtrl->LoadItemsFromFile(ConfigManager::GetFolder(sdConfig) + wxFILE_SEP_PATH + _T("codesnippets.xml"));
I just wanted to repeat, it's not only the two plugins you talk about (dragscroll and keybinder) but also codesnippets. I've now looked into the code and have found this:
<rant>Why does nobody use the forum search???</rant>
Because it's an awful implementation of search. It seems to come up with nothing or everything. The user can't use special characters, and words can't be grouped and {insert more complaints}...
Can you be more specific? I never had problems searching the forums...