Hi Enrico,
We have had a report on IRC that running geany on the windows command line will only open files in the Geany install directory unless you use the full path.
eg C:\somepath> geany somefile.txt
will open installpath\somefile.txt not somepath\somefile.txt.
And with the "Open new documents from the command line" option set it creates somefile.txt in the install dir since it doesn't exist there.
Suspicion is falling on https://github.com/geany/geany/commit/775ef628688c69de34640e12666aed5762a80d...
As the most experienced windowser (and the committer of that change) could you look at it please?
Cheers Lex
Hey,
We have had a report on IRC that running geany on the windows command line will only open files in the Geany install directory unless you use the full path.
eg C:\somepath> geany somefile.txt
will open installpath\somefile.txt not somepath\somefile.txt.
And with the "Open new documents from the command line" option set it creates somefile.txt in the install dir since it doesn't exist there.
Oops. Dammit, I broke this with the mentioned commit. After you said it, it is totally obvious. Well that change was a workaround at all but now we need another workaround. The problem is that some code, I don't remember exactly whether it were only plugins or also Geany code, read resource files from a relative path like "\data\foo.bar". For this to work, the working directory must be set correctly. The reason for the mentioned change was this in some plugin, so I've moved the code to change the working directory to perform it earlier in the init process, before loading plugins. For a quick'n'dirty fix we could either move the working directory change code move after command line parsing code but before plugin loading or we remember the working directory at early stage to use this when llater handling command line arguments. Both are not nice and the real solution is to get rid of relative paths for resources in the installation directory. I'm going to work on this.
As the most experienced windowser (and the committer of that change) could you look at it please?
most experienced windowser? Really not. Using Windows once or twice a year, depending of the amount of Geany releases :).
Regards, Enrico
On 13 March 2013 17:01, Enrico Tröger enrico.troeger@uvena.de wrote:
Hey,
We have had a report on IRC that running geany on the windows command line will only open files in the Geany install directory unless you use the full path.
eg C:\somepath> geany somefile.txt
will open installpath\somefile.txt not somepath\somefile.txt.
And with the "Open new documents from the command line" option set it creates somefile.txt in the install dir since it doesn't exist there.
Oops. Dammit, I broke this with the mentioned commit. After you said it, it is totally obvious. Well that change was a workaround at all but now we need another workaround. The problem is that some code, I don't remember exactly whether it were only plugins or also Geany code, read resource files from a relative path like "\data\foo.bar".
Shouldn't plugins use geany->app->configdir as the base directory as per http://www.geany.org/manual/reference/structGeanyApp.html
and if its Geany it can use GeanyApp.datadir as the system data directory.
For this to work, the working
directory must be set correctly. The reason for the mentioned change was this in some plugin, so I've moved the code to change the working directory to perform it earlier in the init process, before loading plugins. For a quick'n'dirty fix we could either move the working directory change code move after command line parsing code but before plugin loading or we remember the working directory at early stage to use this when llater handling command line arguments. Both are not nice and the real solution is to get rid of relative paths for resources in the installation directory. I'm going to work on this.
Yes it would be better to keep the working dir, ... well ... the working dir :)
As the most experienced windowser (and the committer of that change) could you look at it please?
most experienced windowser? Really not. Using Windows once or twice a year, depending of the amount of Geany releases :).
Well, thats approaching infinitely more often than me (as my use approaches asymptotically zero), Matthew is on holidays, and Colomban denies knowledge of what Windows means :)
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13/03/2013 06:19, Lex Trotman wrote:
Shouldn't plugins use geany->app->configdir as the base directory as perhttp://www.geany.org/manual/reference/structGeanyApp.html
and if its Geany it can use GeanyApp.datadir as the system data directory.
For this to work, the working
directory must be set correctly. The reason for the mentioned change was this in some plugin, so I've moved the code to change the working directory to perform it earlier in the init process, before loading plugins. For a quick'n'dirty fix we could either move the working directory change code move after command line parsing code but before plugin loading or we remember the working directory at early stage to use this when llater handling command line arguments. Both are not nice and the real solution is to get rid of relative paths for resources in the installation directory. I'm going to work on this.
Yes it would be better to keep the working dir, ... well ... the working dir:)
+1, it's best for plugins to use fixed paths and avoid temporarily changing the working dir.
Le 15/03/2013 16:18, Nick Treleaven a écrit :
On 13/03/2013 06:19, Lex Trotman wrote:
Shouldn't plugins use geany->app->configdir as the base directory as perhttp://www.geany.org/manual/reference/structGeanyApp.html
and if its Geany it can use GeanyApp.datadir as the system data directory.
For this to work, the working
directory must be set correctly. The reason for the mentioned change
was
this in some plugin, so I've moved the code to change the working directory to perform it earlier in the init process, before loading
plugins.
For a quick'n'dirty fix we could either move the working directory change code move after command line parsing code but before plugin loading or we remember the working directory at early stage to use this when llater handling command line arguments. Both are not nice and the real solution is to get rid of relative paths for resources in the installation directory. I'm going to work on this.
Yes it would be better to keep the working dir, ... well ... the working dir:)
+1, it's best for plugins to use fixed paths and avoid temporarily changing the working dir.
Agreed. Though, IIUC on Windows it's meant to be dynamic, so it'd require an API the plugins could use to get the sysdir -- or make all plugins use g_win32_get_package_installation_directory_of_module() but it's tedious.
BTW if we want not to change directory anymore, I think we'd need the attached (untested) patch which fixes the only location I found where Geany uses relative paths. Or even apply it now (if it is tested working) so we don't have relative path ourselves anymore.
On 16/03/13 18:23, Colomban Wendling wrote:
Le 15/03/2013 16:18, Nick Treleaven a écrit :
On 13/03/2013 06:19, Lex Trotman wrote:
Shouldn't plugins use geany->app->configdir as the base directory as perhttp://www.geany.org/manual/reference/structGeanyApp.html
and if its Geany it can use GeanyApp.datadir as the system data directory.
For this to work, the working
directory must be set correctly. The reason for the mentioned change
was
this in some plugin, so I've moved the code to change the working directory to perform it earlier in the init process, before loading
plugins.
For a quick'n'dirty fix we could either move the working directory change code move after command line parsing code but before plugin loading or we remember the working directory at early stage to use this when llater handling command line arguments. Both are not nice and the real solution is to get rid of relative paths for resources in the installation directory. I'm going to work on this.
Yes it would be better to keep the working dir, ... well ... the working dir:)
Ok. Just to get it clear, do we want to not change the current working directory at all? Before my change we *did* change it very late in the init process. If we decide to not change it at all, we might lock again the directory where Geany was started as in bug #2626124. As Dimitar noted in this thread, this is not as bad and uncommon as I assumed. So if we all agree on this behaviour, I'd be ok with.
+1, it's best for plugins to use fixed paths and avoid temporarily changing the working dir.
Agreed. Though, IIUC on Windows it's meant to be dynamic, so it'd
Correct.
require an API the plugins could use to get the sysdir -- or make all plugins use g_win32_get_package_installation_directory_of_module() but it's tedious.
Yes. We already have Geany's datadir in app->datadir which can also accessed by plugins though it's of no use for plugins. But it'd be easy to export something like win32_get_installation_dir() or maybe even a utility function which contructs the path for a plugin to be more convenient.
BTW if we want not to change directory anymore, I think we'd need the attached (untested) patch which fixes the only location I found where Geany uses relative paths. Or even apply it now (if it is tested working) so we don't have relative path ourselves anymore.
Tested and works fine. I'd vote to commit it now.
Regards, Enrico
Le 19/03/2013 14:02, Enrico Tröger a écrit :
On 16/03/13 18:23, Colomban Wendling wrote:
Le 15/03/2013 16:18, Nick Treleaven a écrit :
On 13/03/2013 06:19, Lex Trotman wrote:
Shouldn't plugins use geany->app->configdir as the base directory as perhttp://www.geany.org/manual/reference/structGeanyApp.html
and if its Geany it can use GeanyApp.datadir as the system data directory.
For this to work, the working
directory must be set correctly. The reason for the mentioned change
was
this in some plugin, so I've moved the code to change the working directory to perform it earlier in the init process, before loading
plugins.
For a quick'n'dirty fix we could either move the working directory change code move after command line parsing code but before plugin loading or we remember the working directory at early stage to use this when llater handling command line arguments. Both are not nice and the real solution is to get rid of relative paths for resources in the installation directory. I'm going to work on this.
Yes it would be better to keep the working dir, ... well ... the working dir:)
Ok. Just to get it clear, do we want to not change the current working directory at all? Before my change we *did* change it very late in the init process. If we decide to not change it at all, we might lock again the directory where Geany was started as in bug #2626124. As Dimitar noted in this thread, this is not as bad and uncommon as I assumed. So if we all agree on this behaviour, I'd be ok with.
I don't care very much actually, but the idea of not locking the directory from where Geany was started looks sensible.
Is there real issues on cwd()ing apart the option parsing one?
+1, it's best for plugins to use fixed paths and avoid temporarily changing the working dir.
Agreed. Though, IIUC on Windows it's meant to be dynamic, so it'd
Correct.
require an API the plugins could use to get the sysdir -- or make all plugins use g_win32_get_package_installation_directory_of_module() but it's tedious.
Yes. We already have Geany's datadir in app->datadir which can also accessed by plugins though it's of no use for plugins.
Yeah but it doesn't point to somewhere sensible for plugins, it points to either $prefix/share/geany or $geanywininstalldir/data, whereas plugins should look in their own directory.
But it'd be easy to export something like win32_get_installation_dir() or maybe even a utility function which contructs the path for a plugin to be more convenient.
I'm afraid this may be quite hard to achieve because AFAIK plugins are installed inside Geany's directory, right? So it'd probably be really hard to determine where the module's data have been installed…
Moreover g_win32_get_package_installation_directory_of_module() requires a Windows HMODULE and I don't know if one can get that from a GModule.
But if g_win32_get_package_installation_directory_of_module() is able to get the install dir of a plugin, it wouldn't be that hard to fix plugins; though I would think that a convenient API for plugins not to have to bother about that would be cool. However I'm not sure how this would work under !win because here we need to know $PKGDATADIR of the plugin, which is only known at build time (and is not necessarily called $PKGDATADIR on non-autotools build systems)…
Maybe it would be done with a macro, like
#ifdef G_OS_WIN32 # define plugin_get_sysdir(plugin) \ (g_win32_get_package_installation_directory_of_module(plugin->module)) #else # define plugin_get_sysdir(plugin) \ (g_strdup(PKGDATADIR)) #endif
or even more convenient but a little harder to implement would be something like plugin_build_syspath(plugin, ...) -- the problem here being that variadic macros doesn't exist on C89 (hi Lex ;).
This said, if the plugins SO where loaded from their real installation directory we could probably easily determine their datadir from the SO path.
Well… I don't know, those are ideas and reflexions I had when thinking about it.
BTW if we want not to change directory anymore, I think we'd need the attached (untested) patch which fixes the only location I found where Geany uses relative paths. Or even apply it now (if it is tested working) so we don't have relative path ourselves anymore.
Tested and works fine. I'd vote to commit it now.
OK great. Committed.
Hey,
sorry for the delay.
On 19/03/13 17:55, Colomban Wendling wrote:
Le 19/03/2013 14:02, Enrico Tröger a écrit :
On 16/03/13 18:23, Colomban Wendling wrote:
Le 15/03/2013 16:18, Nick Treleaven a écrit :
On 13/03/2013 06:19, Lex Trotman wrote:
Shouldn't plugins use geany->app->configdir as the base directory as perhttp://www.geany.org/manual/reference/structGeanyApp.html
and if its Geany it can use GeanyApp.datadir as the system data directory.
For this to work, the working
> directory must be set correctly. The reason for the mentioned change was > this in some plugin, so I've moved the code to change the working > directory to perform it earlier in the init process, before loading plugins. > For a quick'n'dirty fix we could either move the working directory > change code move after command line parsing code but before plugin > loading or we remember the working directory at early stage to use this > when llater handling command line arguments. > Both are not nice and the real solution is to get rid of relative paths > for resources in the installation directory. > I'm going to work on this.
Yes it would be better to keep the working dir, ... well ... the working dir:)
Ok. Just to get it clear, do we want to not change the current working directory at all? Before my change we *did* change it very late in the init process. If we decide to not change it at all, we might lock again the directory where Geany was started as in bug #2626124. As Dimitar noted in this thread, this is not as bad and uncommon as I assumed. So if we all agree on this behaviour, I'd be ok with.
I don't care very much actually, but the idea of not locking the directory from where Geany was started looks sensible.
Is there real issues on cwd()ing apart the option parsing one?
Excluding the relative path resource loading problem, I don't know of any.
So, we have two options here: a) remove the code to change the working directory on Windows completely, which would cause locking the directory from where Geany was started b) revert my faulty commit to the previous behaviour we had for years: changing the working directory at the end of the init process to not lock the original directory
I personally would vote for b but don't mind much since most votes so far went for a). Just tell me what way to go and I'll change it.
For now, I committed a workaround for Windows to the 1.23 branch to remember the original working directory and use it when resolving relative paths passed on the command line to fix that behaviour. This should do for the 1.23 series, for master we should find a real solution.
require an API the plugins could use to get the sysdir -- or make all plugins use g_win32_get_package_installation_directory_of_module() but it's tedious.
Yes. We already have Geany's datadir in app->datadir which can also accessed by plugins though it's of no use for plugins.
Yeah but it doesn't point to somewhere sensible for plugins, it points to either $prefix/share/geany or $geanywininstalldir/data, whereas plugins should look in their own directory.
True.
But it'd be easy to export something like win32_get_installation_dir() or maybe even a utility function which contructs the path for a plugin to be more convenient.
I'm afraid this may be quite hard to achieve because AFAIK plugins are installed inside Geany's directory, right? So it'd probably be really hard to determine where the module's data have been installed…
Moreover g_win32_get_package_installation_directory_of_module() requires a Windows HMODULE and I don't know if one can get that from a GModule.
Nope to both points: g_win32_get_package_installation_directory_of_module(NULL) works perfectly fine, in Geany and also in plugins. It returns something like c:\program files\geany.
This path could be easily used by plugins to construct their own complete abslute path to any resources.
But if g_win32_get_package_installation_directory_of_module() is able to get the install dir of a plugin, it wouldn't be that hard to fix plugins; though I would think that a convenient API for plugins not to have to bother about that would be cool. However I'm not sure how this would work under !win because here we need to know $PKGDATADIR of the plugin, which is only known at build time (and is not necessarily called $PKGDATADIR on non-autotools build systems)…
Maybe it would be done with a macro, like
#ifdef G_OS_WIN32 # define plugin_get_sysdir(plugin) \ (g_win32_get_package_installation_directory_of_module(plugin->module)) #else # define plugin_get_sysdir(plugin) \ (g_strdup(PKGDATADIR)) #endif
or even more convenient but a little harder to implement would be something like plugin_build_syspath(plugin, ...) -- the problem here being that variadic macros doesn't exist on C89 (hi Lex ;).
Huh? Don't we use them in various places in Geany and Glib uses them as well? Except this, I'd want to implement plugin_build_syspath() like described, just to make plugin authors happy after the plugins broke which used relative paths so far.
Regards, Enrico
On Sat, 18 May 2013 16:12:04 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
or even more convenient but a little harder to implement would be something like plugin_build_syspath(plugin, ...)
scope/src/scope.c: char *helpfile = g_build_filename(PLUGINHTMLDOCDIR, "scope.html", NULL); char *gladefile = g_build_filename(PLUGINDATADIR, "scope.glade", NULL);
Why do we need an entirely plugin_build_syspath() function? Even for a portable Geany, the above directories can be #define-d as functions.
What should plugin_build_syspath() return to cover both directories? Something different, depending on whether the last "..." ends with .glade or .html? Some common prefix?
Maybe we can standartize PLUGIN*DIR instead, including automatically defining them under waf? Currently, the above two directories require 10 LOC of python, including a check for win32 - and I wasn't able to guess the proper definitions without your help.
Also, a C function covers the access, but not the installation...
Except this, I'd want to implement plugin_build_syspath() like described, just to make plugin authors happy after the plugins broke which used relative paths so far.
As a plugin developer, any interface that provides stable, platform indepent plugin directory names will make me happy. Though if I have to re-#define the PLUGIN*DIR-s as different plugin_build_syspath() calls above a certain API version, while still depending on the python code for installation, I will be, how to put it, moderately happy. :)
On 18/05/13 16:12, Enrico Tröger wrote:
Hey,
sorry for the delay.
On 19/03/13 17:55, Colomban Wendling wrote:
Le 19/03/2013 14:02, Enrico Tröger a écrit :
On 16/03/13 18:23, Colomban Wendling wrote:
Le 15/03/2013 16:18, Nick Treleaven a écrit :
On 13/03/2013 06:19, Lex Trotman wrote:
Shouldn't plugins use geany->app->configdir as the base directory as perhttp://www.geany.org/manual/reference/structGeanyApp.html
and if its Geany it can use GeanyApp.datadir as the system data directory.
For this to work, the working >> directory must be set correctly. The reason for the mentioned change > was >> this in some plugin, so I've moved the code to change the working >> directory to perform it earlier in the init process, before loading > plugins. >> For a quick'n'dirty fix we could either move the working directory >> change code move after command line parsing code but before plugin >> loading or we remember the working directory at early stage to use this >> when llater handling command line arguments. >> Both are not nice and the real solution is to get rid of relative paths >> for resources in the installation directory. >> I'm going to work on this. Yes it would be better to keep the working dir, ... well ... the working dir:)
Ok. Just to get it clear, do we want to not change the current working directory at all? Before my change we *did* change it very late in the init process. If we decide to not change it at all, we might lock again the directory where Geany was started as in bug #2626124. As Dimitar noted in this thread, this is not as bad and uncommon as I assumed. So if we all agree on this behaviour, I'd be ok with.
I don't care very much actually, but the idea of not locking the directory from where Geany was started looks sensible.
Is there real issues on cwd()ing apart the option parsing one?
Excluding the relative path resource loading problem, I don't know of any.
So, we have two options here: a) remove the code to change the working directory on Windows completely, which would cause locking the directory from where Geany was started b) revert my faulty commit to the previous behaviour we had for years: changing the working directory at the end of the init process to not lock the original directory
I personally would vote for b but don't mind much since most votes so far went for a). Just tell me what way to go and I'll change it.
I went for c):
in GIT master, Geany now changes the working directory after handling files passed on the command line and before loading plugins.
So everything should be fine, at least it was my in tests.
Regards, Enrico
On Wed, 13 Mar 2013 11:26:19 +1100 Lex Trotman elextr@gmail.com wrote:
We have had a report on IRC that running geany on the windows command line will only open files in the Geany install directory unless you use the full path.
Suspicion is falling on https://github.com/geany/geany/commit/775ef628688c69de34640e12666aed5762a80d...
As the most experienced windowser (and the committer of that change) could you look at it please?
git 775ef628688c69de34640e12666aed5762a80dff: [...] "see bug #2626124"
I work with Win~1 daily, and can assure you that it's pretty normal for an NT based system to lock a directory from which a file was open, until the program which opened the file is exited. Hell, even Explorer can lock a directory, for example by reading the pictures in it to show previews - you can delete all files, but have to kill Explorer and start it again via Task Manager to remove the directory.
--
On Wed, 13 Mar 2013 07:01:11 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
The problem is that some code, I don't remember exactly whether it were only plugins or also Geany code, read resource files from a relative path like "\data\foo.bar".
s/buggy_code/g_build_filename(GEANY_DATADIR|PLUGINDATADIR, ...)/g
I use good file manager and never specify files to open from the command line (cmd is a lame shell), so I never noticed this bug...