"Portable" Code::blocks?

[Vexorian]

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

[stahta01]

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

If you compile C::B from source look at my patch
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1783&group_id=5358
and at this thread
http://forums.codeblocks.org/index.php?topic=4475

Tim S

[Pecan]

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

What version of CB are you using. I don't think CB uses the windows registry except in the older RC2 version.

Try a nightly build.

[dje]

Hi !

I 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

[mandrav]

Hi !

I 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>

[stahta01]

Hi !

I 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>

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.

Tim S

[Pecan]

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

I've found that google does a better job with"
"site:codeblocks.org {your search parameters}" or
"site:forums.codeblocks.org {your search parameters}"

[mandrav]

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

[thomas]

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.

[Pecan]

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.

Those plugins are asking CB where it should store and find its config files.
So what's the call to get that information if not GetconfigFolder() ?

Is there a "GetConfusingCurrentConfigFolder()" call?

@Tim
Maybe you should just patch an entirely new GetCurrentConfigFolder(). Then thomas can use his and the rest of us could get the necessary info needed to make the plugins work correctly.

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.

Here is another reason I've suggested that a plugin be as loosely coupled to the sdk as possible. It's getting such that a plugin just gets in trouble depending on it.

It looks like keybinder and dragscroll will have to de-couple from the sdk even  more and start searching the directories themselves. Oh well....

[wxLearner]

It looks like you have to use "GetConfigFolder" as if it were called "GetDefaultConfigFolder" and, if it fails, search in the executable's directory yourself. I think it would be nicer to refactor the current "GetConfigFolder" to "GetDefaultConfigFolder" and make the "GetConfigFolder" API return the config folder, that should actually be used.

Obviously some plugin writers thought "GetConfigFolder" would already return the currently used config folder, so their plugins would work automatically. I think the CodeSnippets plugin also expects to find it's config just by using "GetConfigFolder", doesn't it? I don't know about other plugins using this API, but the config files in my profile seem to be concerning these three plugins only.

[mandrav]

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.

People, listen to Thomas. He 's right and you are missing his point.
Although I do see the need for keeping the user's home folder clean, in case you use C::B off of a usb stick on a foreign computer (and so you don't want to pollute the user's config folder).

@Thomas: how about this:
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...

[TDragon]

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:
1. Add a search flag such as "sdAnyConfigLocation" or change the behavior of ConfigManager::LocateDataFile so that "sdConfig" searches all possible locations
2. Add some functionality to ConfigManager::GetFolder that returns whichever directory C::B's primary .conf file was read from for "sdConfig" (and "sdAnyConfigLocation")
3. Strongly recommend that plugins use ConfigManager::LocateDataFile with said flag for locating their config files, and GetFolder(sdConfig) to figure out where to create them

Seems to me like that would A) let plugin writers manage configuration with a minimum of hassle -- if LocateDataFile fails, create a new config file in whichever folder GetFolder(sdConfig) returns; and B) allow for relocation with a minimum of hassle: users can move the contents of the config directory, or even just their personality.conf -- and when they install new plugins after moving their settings, GetFolder will ensure that the new plugins' settings files are created alongside.

Just my two cents.

EDIT:
That'll teach me to read before posting. Yeah, I totally missed thomas' point about non-writable storage. A check for writability would definitely need to be added somewhere in the above scheme.

-JohnE / TDragon

[stahta01]

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.

To fix the two plugins the only part needed to be patched is the .h file. I added the rest of the code per request from Code::Blocks Team. I agree that my patch does ad (2.) but I am not sure it should NOT do that.

Tim S

[thomas]

@Thomas: how about this:
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...

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.

As it is now, it will read the config file from the user's profile folder (where it is normally, and where it belongs). This is "normal" operation which 95% of all users will want 95% of the time.

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!

However, it is still possible to copy a config file to the user's profile folder, and Code::Blocks will use that one, even when launched from CDROM. Thus, different users can still customise their program with persistent settings the way they want it, even if they don't have the program on the hard disk at all and they all share one copy on a CDROM. All it takes is copying the config file from the CDROM to the profile folder once.

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