As reported on the xfce-dev mailing list, the panel does not properly handle systems with both 32 and 64 bit libraries because the plugin path is hard-coded in the desktop file. Brian suggested to fix this by using the $libdir during compilation *inside* the panel, since that variable will point to /usr/lib<bit> during compilation.
FYI: During startup the panel traverses the XDG_DATA_DIRS for desktop files in the xfce4/panel-plugins directories. If a desktop file is found, the path and module name are read to open the plugin. SO plugins don't necessarily need to be installed in the same directory as the panel, so system users can add their own plugins in the home directory. The problem of using $libdir is that it contains a full path, while we basically can looks for $datadir/../lib<bits>/xfce4/panel-plugins.
Is there use-case for allowing arbitrary plugin locations? I really only see a need for a system location and a user location. The system location can be $panel_libdir/xfce4/panel-plugins, and the user location can be something in ~/.local/lib. Still this doesn't really solve the problem completely. Users with NFS-mounted homedirs would have a problem with using ~/.local/lib if their homedir is mounted on different arches -- note I'm not just talking about a lib32/lib64 distinction, but an x86/sparc distinction as well. In this case, the bug summary is probably not quite what it should be. Anyway, not sure how much you care about supporting per-user plugins with different arch support. Might not be worth the effort. The system location stuff is further complicated by the fact that we use $XDG_DATA_DIRS for the .desktop file location, but there's no analogous $XDG_LIB_DIRS. As you said, you can look in $DATA_DIR/../lib##/xfce4/panel-plugins/, but that's not great either, since XDG_DATA_DIRS is arbitrary and need not be in the usual "$prefix/share/" form. Plus you have to figure out 'bitness,' to fill in lib##, which isn't great either.
Another option is letting g_module_open look for the library using a relative path (g_module_open ("liblauncher.so", 0)), but this only works when the directory is specified in ld.so.conf.
Looking at KDE, they install all the plasma applets in $prefix/lib, so they can pass a library name to dlopen. Like I said in my previous comment. Not very clean (lots of files in the lib dir), but it might actually be the best solution for us.
Any opinions/suggestions on this? The two best options we have right now: 1) Search only in hard-coded paths for desktop files and libs. We look in $datadir/xfce4/panel-plugins for .desktop files, the module should exist in $libdir/xfce4/panel-plugin. This should fix the issues for the distributions. For users we poke ~/.local/share/xfce4/panel-plugins and then the plugin should exist in ~/.local/lib/xfce4/panel-plugins. Assuming there are no multiple architectures there. Possible problems: plugin not found if the user installs it in another path then the panel and the NFS-problem for ~/.local, see Brian's comment. 2) Install all the plugins in $libdir and use a relative name during module loading so ld.so will lookup the module for us. Possible problems: a bunch of plugins in the lib dir and the path should be in /etc/ld.so.conf. PS. CC-ed some more devs, since this is quite important for the panel and will affect it even more when all plugins are compiled as libraries in 4.8. So maybe someone has a brilliant idea.
I've decided I'm going to hard-code the path to the plugins in the 4.8 panel to $(libdir)/xfce4/panel-plugins. This means no user-location support anymore, until there is a proper implementation for this in the xdg spec. The desktop files will only contain the library name (for example: launcher). Then panel will then look for liblauncher.so in $prefix/lib/xfce4/panel-plugins.
Well, then at least we will find out if people actually use(d) that feature :)
As a fallback we could use the unofficial variable $XDG_LIB_HOME which was discussed on the xdg list a while ago. So two locations for plugins desktop files with matching libraries: - look in the hard-coded compile time paths: {$libdir,$datadir}/xfce4/panel-plugins/ for plugins/desktop-files. - look in {$XDG_LIB_HOME,$XDG_DATA_HOME}/xfce4/panel-plugins for plugins/desktop-files. Use $HOME/.local/lib if $XDG_LIB_HOME is not defined. Then we only drop support for $XDG_DATA_DIRS we have right now, because we cannot safely determine the library path from the desktop file.
Hmm, probably best not to use $XDG_LIB_HOME until it gets into a spec. I was involved in the discussion about it on xdg-list, and there's no consensus. Actually, talk has died down :-( .
Ok, well then only the hard-coded location for now.
Devel branch has been merged in master. A 4.7.0 release will follow soon. If you think this bug is not fixed? Feel free to reopen the bug.
Hello guys, I am working panel plugin on debian wheezy (XFCE 4.8) and I see that user plugins as been disabled by this bug fix. I think it is quite anoying for a developper to compile/debug a plugin while being in root. I guess I am not alone in this case. -> Is there a way to develop plugins without being root ? -> Are you interested if I re-enable this functionality (user plugins) by implementing something like described in the comment #8, perhaps using another variable than XDG_LIB_HOME since it is not yet specified) ?