[Geany-Devel] Setting Windows working directory

[Colomban Wendling]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.geany.org/pipermail/devel/attachments/20130319/6577ac1a/attachment.pgp>