Like i've done in several panel plugins, let's build it as a module loadable by panel wrapper. This should be compatible with panel 4.8 and 4.10, for when you want to drop compatibility with panel 4.6. Oh, and you could add an about dialog for the plugin by linking with src/about-xfcalendar.c and connect create_wAbout() to 'about' signal in oc_construct().
Created attachment 4336 Build the plugin as a module
Why would I do this? That about dialog is good idea.
(In reply to comment #2) > Why would I do this? Hmm.. consistency with other plugins, compliance to new-style plugins and paths ?
juha, ping ? can you apply this ? not many plugins are still built as binaries...
I'm about to send a patch to fixup thunar and start looking at the rest of the commonly used panel plugins, but based on my system, orage will be the only one left still doing it the "old" way.
Created attachment 5964 For consistency with other panel plugins juha, would you at least apply the attached patch to put the panel plugin desktop file in $(datadir)/xfce4/panel/plugins/ instead of $(datadir)/xfce4/panel-plugins/ to be be consistent with the other panel plugins?
(In reply to Robby Workman from comment #6) > Created attachment 5964 > For consistency with other panel plugins > > juha, would you at least apply the attached patch to put the panel plugin > desktop file in $(datadir)/xfce4/panel/plugins/ instead of > $(datadir)/xfce4/panel-plugins/ to be be consistent with the other panel > plugins? I do not think this patch changes anything. As far as I understand desktopdir is not used. Need to test more. Did you test this?
desktopdir is used to install the desktop file pointing at the plugin. On an xfce system look at the list of files installed in $prefix/share/xfce4/panel-plugins and $prefix/share/xfce4/panel/plugins/. The 2nd dir is now the preferred location for desktop files, and similarly for the plugin/binary ($prefix/lib/xfce4/panel-plugins vs $prefix/lib/xfce4/panel/plugins) itself. Again, if you really look at http://bug-attachment.xfce.org/attachment.cgi?id=4336 and all the other panel plugins in the ecosystem, it's all a matter of wanting to align with the rest of Xfce for consistency. If you dont want/care about following the rest of Xfce guidelines, fine. Oh, and yeah, usually when we post diffs we test them beforehands...
While I won't speak for Landry's patch, I can say for certain that mine is tested, and it's being used in my unofficial Slackware packages and will be in the official Slackware packages that are already built but not yet public. http://rlworkman.net/pkgs/14.1/testing/src/xfce-4.12/xfce4-mixer/
Oops, wrong component pasted, and actually, no, I'm not shipping this patch yet because it's not yet upstream; however, it has been tested to work. The better approach is to merge Landry's patch though, as it accomplishes both goals.
ok, I applied this to version 4.11.2.22. I could not really test that it works, but at least distcheck still works. Very scary stuff.
Thanks... but why do you think this is "scary" ? All/most panel plugins moved to this scheme some years ago ... and we didnt have issues with it.
I only mean that while coding is fun and easy...doing these autotools and git changes is not easy nor fun, but instead very scary. And in my opinion these changes really do not give anything back. New version, new standards. Just moving files to new locations and renaming them. When I last time changed the plugin name, it caused big load of not so nice comments from several distro maintainers. We will see if it now goes better. And it is very difficult and time consuming to test these changes so that it works for all versions and distros.