Comment 5 for bug 1315536

Right, I now understand why some desktop files are failing to sort, even though menulibre is doing its job and sorting them properly + generating the correct layout entry etc.

The examples I have are K3b in the Multimedia category and Basket Notepads in the Office category. Both are KDE programs - through going through the gnome-menu-spec-test output I can see that GMenu is adding the 'kde4-' prefix to the desktop filename after the initial loading. This has the effect that the mangled desktop filename no longer matches the entry under the Layout node, and therefore its position is not specified, so it ends up at the bottom of the list.

Looking at the spec (https://standards.freedesktop.org/menu-spec/menu-spec-latest.html), around 'To prevent that a desktop entry from one party inadvertently cancels out', this appears to be a 'vendor prefix' addition - the desktop files are stored in '/usr/share/applications/kde4/', as compared to everything else being in '/usr/share/applications' - so clearly its pulling the prefix from this subdirectory name.

Since there are no other subdirs on my system, effectively this is just a KDE desktop file mangling problem. A quick look at two test VMs with GNOME stuff installed shows that their desktop files are stored in '/usr/share/applications' and have 'gnome-' as part of the filename.

I'm going to look into how the layout nodes are generated and add this mangling hack, since it seems to be part of the standard (presumably you want to keep this out of menulibre proper since from our perspective it seems to just be a problem affecting the layout stage?).