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

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6610
    • 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 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2165
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: 4291
    • 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: 2165
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.

Offline wxLearner

  • Multiple posting newcomer
  • *
  • Posts: 71
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: 2165
Re: "Portable" Code::blocks?
« Reply #21 on: February 07, 2007, 05:58:58 pm »
Code: [Select]
[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: [Select]
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: [Select]
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: 2165
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: 4291
    • 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: 2165
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: 6610
    • 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: [Select]
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 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2165
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: [Select]
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."