Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Standard conforms config- and userdata-paths - Patch(es) to test
oBFusCATed:
--- Quote from: jens on February 01, 2015, 10:02:21 am ---We also have dependencies on several other third-party libs, like e.g. gtk+ .
--- End quote ---
I think we will be able to drop this dependency when we switch to wx30.
--- Quote from: jens on February 01, 2015, 10:02:21 am ---I worked on this patche(es), because I got mails from other (linux) developpers and maintainers, that asked for more standard-compliancy.
--- End quote ---
I like the idea, so I'm not against the change.
I just don't like that we bring another dependency for just a simple function.
--- Quote from: jens on February 01, 2015, 10:02:21 am ---Currrently I do not have the power or the time to work much on C::B...
--- End quote ---
No problem with that, could you give me raw git patches, so I can continue your work?
Jenna:
Changing the patches so we use self-contructed paths is not the problem.
The problem is to make sure it behaves correctly (checking env-vars etc.).
It can be done but it does not make sense and is probably error-prone (at least in some cases).
wxGTK already depends on glib, so it is not really a new dependency.
I have no time and power to bug the wx-devs to get it into wxGTK, the greatest problem here might be the backwards-compatibility.
All applications that use the existing functions would need to be overworked and that's something the wx-devs don't like most of the time.
And wx3.0 compatibility is still far away.
By the way:
I think we should drop the wx2.8 compatibility as soon as possible after moving to wx3, because the actual code is already cluttered with compatibility-ifdefs and hard to maintain therefore.
oBFusCATed:
--- Quote from: jens on February 01, 2015, 02:37:18 pm ---wxGTK already depends on glib, so it is not really a new dependency.
--- End quote ---
From the point of view of C::B it is abstracted away. If you want to go with the glib dependency, you'll have to change the spec file and probably the debian files.
--- Quote from: jens on February 01, 2015, 02:37:18 pm ---I think we should drop the wx2.8 compatibility as soon as possible after moving to wx3, because the actual code is already cluttered with compatibility-ifdefs and hard to maintain therefore.
--- End quote ---
+1 here.
oBFusCATed:
BTW:
I'm not really sure we should do the folder migration ourselves.
There are plenty of problems that might occur and the chance for data loss is not small.
For example I have symlinks in the ~/.codeblocks folder and I doubt the new code will handle them correctly.
Also running old and new versions might be problematic. I suppose, I'll add a ~/.codeblocks symlink for the first couple of months, just in case.
So, I'd rather prefer if C::B either:
1. exists with an error telling the user he/she must migrate the settings
2. just print a warning that the old location is used and urging the user to move them to the new location manually.
frithjofh:
maybe write a one shot plugin which takes care of the appropriate changes for the user... (moving the config files and everything else necessary)
feel free to laugh or sneer at the proposal :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version