[Feature Request] Ability to alphabetically sort menu directory contents

[OmegaPhil]

I'm interested in alacarte replacements - while debugging alacarte I found your program :) Other than a generally-working menu editor, I'm interested in alphabetical sort of a menu directory, to save me from lots of moving up/down of menu items.

Please could you implement such an alphabetical sort?

[OmegaPhil (omegaphil)]

Looking into this, would it make sense only to allow sorting of child menus of the parent menu? So that you can't break the overall menu structure.

[Sean Davis (bluesabre)]

I think that all elements that are a child of the selected node would be sorted. So if you sort the below parent, Children 1, 2, 3 would be included in the sort, but not 2a and 2b.

- Parent
-- Child 1
-- Child 2
--- Child2a
--- Child2b
-- Child 3

[OmegaPhil (omegaphil)]

On 18/07/16 04:20, Sean Davis wrote:
> I think that all elements that are a child of the selected node would be
> sorted. So if you sort the below parent, Children 1, 2, 3 would be
> included in the sort, but not 2a and 2b.
>
> - Parent
> -- Child 1
> -- Child 2
> --- Child2a
> --- Child2b
> -- Child 3

OK, that will in effect keep me away from sorting the top level, which
is good (the top level tends to have more meaning than just a basic
alphabetical sort).

[OmegaPhil (omegaphil)]

I have sorting (case-insensitive alphabetic non-stable sort) generally implemented now, I'm hoping one last problem to track down.

Currently directories are sorted like anything else. Should I split the sort into 2 stages, sorting directories at the top, then the rest below? Since there should be few directories for normal people's menus, I have left it at the basic sort so far.

[OmegaPhil (omegaphil)]

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?).

[OmegaPhil (omegaphil)]

Done - the correct sort is now permanent.

[Sean Davis (bluesabre)]

This patch works perfectly. Applied at https://bazaar.launchpad.net/~menulibre-dev/menulibre/master/revision/343

Thanks!