Project Organizer: Help-Button not working

[frlan]

At least under MacOS 10.11.6 running 1.29 the Help-button inside Tools->Plugin Manager is getting activated, but seem not to work.

[techee]

@frlan This isn't related to projectorganizer only but happens for every plugin. The problem is that right now the installation path of the documentation is defined statically at the compilation time. This works for Linux where the documentation is always at the same location but doesn't work for Windows or OS X where the documentation is relative to the installation path (or the location of the bundle).

This would have to be fixed in Geany which should specify the location of its documentation relatively to the binary.

[eht16]

On Windows, it is not completely broken for every plugin.
The following plugins (from the whole list of plugins available on Windows and have any Help reference implemented) are broken:

• commander
• geanyctags
• scope

A working example is:
geanygendoc

@techee we have ifdef's for MINGW in the Makefiles of some plugins which take care to make the documentation relative.
This could be ported for MacOS I guess but I agree a more generic solution would be nicer.
Maybe we should add some convenience or helper function to the API which helps plugins to construct the path at runtime with the help of the installation directory.

[techee]

I went through other plugins and most of them use the online html version of the documentation which is probably the easiest solution. I created a pull request for geanyctags and projectorganizer here: #521.

[techee]

So I just ran into this problem at another place

geany/geany-osx#6

where some data files aren't read because absolute paths are used in the code. There are at least 5 plugins affected by this - I didn't notice this myself because I have these files installed at the given paths but people who only get the bundle run into this problem.

So now the question is what to do - there are unfortunately various problems:

1. Geany installation prefix can be different from the plugins installation prefix. So Geany itself should probably not contain the code for determining plugins data directory.
2. On OS X Geany and plugins can be built in two ways - without bundle (installed similarly to linux) and with bundle (all in one package). The first one is actually always done in order to create the bundle and is also useful for testing (apart from it also e.g. MacPorts uses this method) while the bundle is what normal users get from the Geany downloads site. Both of them are important and should be supported. This means that the correct method for determining path has to be determined dynamically unlike Windows or Linux where either relative or absolute paths are used and this cannot be done during configure.
3. There's no nice way to determine whether bundle is used or whether Geany is run from system paths. While there are some utility functions for this in the gtk-mac-integration library which Geany uses, this would mean this library has to be added as a dependency for all the affected plugins and this is something I'd like to avoid. The only method I'm aware of is to check if some of the environment variables defined by the launcher script are defined and if so, assume it's a bundle.
4. It would be nice to have the code determining the path at one place but because (1) isn't probably the good solution and because there's nothing like utilities library for geany-plugins, the code will have to be copied to all the affected plugins.

Taking the above into account I tried the following for the GeniusPaste plugin:

static gchar *get_data_dir(void)
{
    gchar *prefix = NULL;
    gchar *dir;

#ifdef G_OS_WIN32
    prefix = g_win32_get_package_installation_directory_of_module(NULL);
#elif defined(__APPLE__)
    if (g_getenv("GTK_PATH"))
        return g_build_filename(g_getenv("GTK_PATH"),
                    "share", "geany-plugins", PLUGIN, "pastebins", NULL);
#endif
    dir = g_build_filename(prefix ? prefix : "", PLUGINDATADIR, "pastebins", NULL);
    g_free(prefix);
    return dir;
}

For the bundle, GTK_PATH is defined and basically points to what /usr would contain on linux. When it's not defined, I assume it's not a bundle and that PLUGINDATADIR can be used. I tested this both for the bundle and non-bundle case and it works.

Is it OK to have a function like that copied to every affected plugin (basically the ones referencing either PLUGINDATADIR in the code or g_win32_get_package_installation_directory_of_module())? Or does anyone have a better idea how to do this?

cc @b4n

[techee]

I changed project organizer to point to the online documentation quite a while ago so this issue isn't present any more.