Hi. Given the recent adjustments to the specifications concerning ".desktop" entries and Gnome's menu system, I've noticed that there are some ebuilds in portage which set up such entries incorrectly. The net-nntp/pan ebuild happens to be one of these. The symptoms of an incorrect entry seem to be either: a) the icon/entry doesn't appear at all (I've encountered others who have complained accordingly). b) it appears in a new "orphaned" sub-menu with the same name as the original sub-menu in which it was originally supposed to appear and this new sub-menu has a generic folder icon. Either way, it's an annoying glitch, especially given that gnome-2.10 has no immediately apparent way to edit menus and that the solution would not be intuitive for a newbie. In the case of Pan, my proposed fix is simple: 1) Install the entry to /usr/share/applications (not /usr/share/gnome/apps/Internet) 2) Add a line containing the text "Categories=Application;Network;" to the stock entry provided by Pan itself. I'm attaching revision bumps for both versions currently available in portage. I think this issue might be worth considering in a broader context; right now I know net-nds/gq to be affected but I suspect that quite a few other packages will be similarly affected too.
Created attachment 62535 [details] net-nntp/pan-0.14.2-r1.ebuild Corrects invalid desktop entry.
Created attachment 62537 [details] net-nntp/pan-0.14.2-r1.ebuild (typo correction) Sorry, that last attachment contained mistakes. Corrected here.
Created attachment 62538 [details] net-nntp/pan-0.14.2.91-r3.ebuild Corrects invalid desktop entry.
Created attachment 62540 [details] net-nntp/pan-0.14.2-r1.ebuild (grammar pedantry) While we're at it, let's correct the grammar for the pkg_setup() comment (should be "have" instead of "of") :p
Created attachment 62541 [details] net-nntp/pan-0.14.2.91-r3.ebuild (grammar pedantry) Same for the unstable version.
Then all the translations is missing .. rather just patch the existing .desktop with the category info, and the makefile to install to the proper location.
I don't understand with regard to your first point. It does just add the category info. No other changes are made to the entry whatsoever so how are the translations lost? However, I do understand what you are suggesting in terms of how the fix is implemented (patch both the desktop entry file itself and the Makefile to set the correct location). I'll try to revise the approach then.
Oh, crap, sorry .. I am blind. I just quickly checked it over, and I guess for some reason I thought it might be using make_desktop_entry from eutils.eclass. No idea why.
OK Martin, no worries. I'll leave these ebuilds as-is then unless you or anyone else really think it's worth the effort to make Makefile patches. My concern is that there is an unknown quantity of packages that could need similar treatment (at least until they're fixed upstream) and that, because this is a simple (and functionally correct) fix, it stands the best chance of being a workaround that's commonly applied. And that's all I'm asking really. On a slightly different note I've noticed that none of the entries for *any* of the 3rd party applications seem to specify that startup-notification should be used. This makes the behaviour inconsistent with core gnome applications. In view of all this stuff, would it be too far-fetched to consider that a desktop entry "sanitiser" function might actually go into the gnome eclass (a common routine to ensure that entries end up in the right place and adhering to freedesktop.org specs)? Just a thought ...
I rather did it via a patch, as it should go upstream. New revisions commited. Added a bug upstream: http://bugzilla.gnome.org/show_bug.cgi?id=309399 As for the rest ... adding it to the gnome eclass will probably not work, as many things (pan included) do not use it ... rather maybe something portage side, but I do not know how open the portage devs will be to that.
OK, I'll follow your example if I submit any further bugs akin to this one. Thanks for fixing (and taking the time to file it upstream).
I suppose you're using "stable" gnome-menus because this issue has been partially fixed in CVS two months ago (see http://bugzilla.gnome.org/show_bug.cgi?id=171366) and, for example, pan works without problems for me with gnome-menus 2.10.2 (and with gnome-menus-2.10.1, but I don't remember if I patched the sources in my overlay or if the fix was included).
