Author Topic: "Portable" Code::blocks?  (Read 34081 times)

Vexorian

  • Guest
"Portable" Code::blocks?
« on: February 06, 2007, 12:27:56 am »
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..



Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: "Portable" Code::blocks?
« Reply #1 on: February 06, 2007, 12:46:05 am »
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
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #2 on: February 06, 2007, 05:01:42 am »
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.

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: "Portable" Code::blocks?
« Reply #3 on: February 06, 2007, 11:35:48 am »
Hi !

Quote
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

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Portable" Code::blocks?
« Reply #4 on: February 06, 2007, 12:13:17 pm »
Hi !

Quote
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>
Be patient!
This bug will be fixed soon...

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: "Portable" Code::blocks?
« Reply #5 on: February 06, 2007, 12:23:01 pm »
Hi !

Quote
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
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #6 on: February 06, 2007, 02:52:48 pm »
<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}"
« Last Edit: February 06, 2007, 02:54:28 pm by Pecan »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Portable" Code::blocks?
« Reply #7 on: February 06, 2007, 03:11:38 pm »
<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...
Be patient!
This bug will be fixed soon...

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: "Portable" Code::blocks?
« Reply #8 on: February 07, 2007, 12:24:25 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #9 on: February 07, 2007, 01:27:42 pm »

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....
« Last Edit: February 07, 2007, 01:48:00 pm by Pecan »

wxLearner

  • Guest
Re: "Portable" Code::blocks?
« Reply #10 on: February 07, 2007, 01:36:16 pm »
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.
« Last Edit: February 07, 2007, 01:53:43 pm by wxLearner »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Portable" Code::blocks?
« Reply #11 on: February 07, 2007, 01:56:53 pm »
Quote from: thomas
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...
Be patient!
This bug will be fixed soon...

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: "Portable" Code::blocks?
« Reply #12 on: February 07, 2007, 02:15:52 pm »
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
« Last Edit: February 07, 2007, 03:35:43 pm by TDragon »
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: "Portable" Code::blocks?
« Reply #13 on: February 07, 2007, 03:26:06 pm »
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
« Last Edit: February 07, 2007, 03:29:35 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: "Portable" Code::blocks?
« Reply #14 on: February 07, 2007, 03:34:11 pm »
@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.
« Last Edit: February 07, 2007, 03:36:10 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: "Portable" Code::blocks?
« Reply #15 on: February 07, 2007, 03:55:55 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.

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
« Last Edit: February 07, 2007, 03:58:33 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #16 on: February 07, 2007, 03:58:37 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.

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.

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


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.

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.


Finally. Thank you.
« Last Edit: February 07, 2007, 04:05:05 pm by Pecan »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Portable" Code::blocks?
« Reply #17 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!

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.
Be patient!
This bug will be fixed soon...

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #18 on: February 07, 2007, 04:16:18 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!

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.


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

  • Guest
Re: "Portable" Code::blocks?
« Reply #19 on: February 07, 2007, 04:18:55 pm »
Quote from: mandrav
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.
« Last Edit: February 07, 2007, 04:21:23 pm by wxLearner »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: "Portable" Code::blocks?
« Reply #20 on: February 07, 2007, 05:48:21 pm »
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 :)

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


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.
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. :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #21 on: February 07, 2007, 05:58:58 pm »
Code
[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]

Way over complicated and unuseful.

Offline artoj

  • Almost regular
  • **
  • Posts: 206
  • Location: Supporting my team
    • http://ajonsson.kapsi.fi/
Re: "Portable" Code::blocks?
« Reply #22 on: February 07, 2007, 06:51:26 pm »
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?

I don't mean to hijack this thread or anything but I can't get that to work. I tried both Windows (rev 3577) + Ubuntu Edgy (rev 3583), both wxW 2.6.3p2. In Windows using a remote config just closes C::B, nothing happens. In Ubuntu I got a core dumped message. GDB output also had some problems in fact, GDB went to an infinite loop while I was debugging.

This is the output from the first run:

Code
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

Second run:

Code
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)
« Last Edit: February 07, 2007, 06:54:41 pm by artoj »

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: "Portable" Code::blocks?
« Reply #23 on: February 07, 2007, 08:38:59 pm »
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.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #24 on: February 07, 2007, 09:33:23 pm »
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.

I've been stung too many times to try to stick to the sdk. I'd rather spend my time creating something new and running down current bugs.

All thats needed for now is a function that returns the path to where core CB  is going to read and write its .conf . If the core CB doesnt want a plugin to write, it can say so. But at least a plugin could read its ini, databases, text files, whatever.

I think it's a simple request.


 
« Last Edit: February 07, 2007, 09:37:02 pm by Pecan »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Portable" Code::blocks?
« Reply #25 on: February 07, 2007, 11:14:09 pm »
Quote
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.

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...
Be patient!
This bug will be fixed soon...

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #26 on: February 07, 2007, 11:48:06 pm »
Quote
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.

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

I said: "write code tightly coupled to the sdk".

It appears you've already made up your mind. I don't care to discussion it further.

I'll take care of it myself. Then offer the code to others to make all our lives a little easier and CodeBlocks a little more pliable for the contributing programmer and reliable for the portable user.
« Last Edit: February 08, 2007, 12:02:25 am by Pecan »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: "Portable" Code::blocks?
« Reply #27 on: February 08, 2007, 01:19:22 am »
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 S

Code
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());
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #28 on: February 08, 2007, 02:03:25 am »
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 S

Code
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());

Thanks Tim, I'll give it a try.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: "Portable" Code::blocks?
« Reply #29 on: February 08, 2007, 10:07:38 am »
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.
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...  ;)


@Artoj: I haven't tested that recently, last time I tried was around June 2006 when it worked nicely. But even if it does not work, I won't look into it at this time either, because nobody really uses it now, and the horrible wxWidgets-based implementation will be replaced with a much nicer and more powerful cURL-based one in the not-so-far future (which is obviously entirely different).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

wxLearner

  • Guest
Re: "Portable" Code::blocks?
« Reply #30 on: February 08, 2007, 11:03:42 am »
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:
Quote from: codesnippetswindow.cpp
Code
// Load the snippets
m_SnippetsTreeCtrl->LoadItemsFromFile(ConfigManager::GetFolder(sdConfig) + wxFILE_SEP_PATH + _T("codesnippets.xml"));
It looks like Pecan is not the onlyone, who misinterpreted "ConfigManager::GetFolder"...
I think it's nice, that it's planned to make it possible to load the config from the web, but why shouldn't it be allowed to store other config files (e.g. even a sqlite db) too? For now it would be enough to just get the path to the currently used location without having to rewrite the logic, which Code::Blocks uses to get it. So a portable version of Code::Blocks with all contributed plugins and many many preconfigured libs could be made NOW and the life of beginners could be much easier 8) Also there could be even more motivation for users to start with Code::Blocks, if a preconfigured version with really many libs, that could be used out of the box, would exist.

Nevertheless Code::Blocks is the best :D

Offline artoj

  • Almost regular
  • **
  • Posts: 206
  • Location: Supporting my team
    • http://ajonsson.kapsi.fi/
Re: "Portable" Code::blocks?
« Reply #31 on: February 08, 2007, 11:56:07 am »
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:

Actually... uh...

Look, a flying whale! *points to random direction*

*runs*

Seriously though, I use ConfigManager in Code snippets to save _config_. Snippets are in a separate XML file. The remote config feature is a good argument to use ConfigManager everywhere though.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #32 on: February 08, 2007, 09:11:53 pm »
<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...

Go to the forum index and search for ".deb"
Can't be done. Not even with quotes.

Now go to Google and enter site:forums.codeblocks.org .deb
All you'll get is the info for .deb, just like you wanted.

This is just one example of many.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: "Portable" Code::blocks?
« Reply #33 on: February 24, 2007, 12:44:52 am »
KeyBinder Fixed SVN 3539

KeyBinder now uses the cbKeyBinder##.ini file when found in the codeblocks executable directory.