Hi Jasper

Thank you for this very clear explanation of alacarte's behaviour.

Also great that you are willing to give the locally-stored .desktop files in /home/<>/local/share/applications/ more meaningful file names.

There is one issue with which the menu specification you quote above does not deal. In our case, it arose because the newish Nemo File Manager (installed after the rather catastrophic functionality stripping in Nautilus, its parent) does not install any .desktop file in the system or user directories (bug reported on the Linux Mint launchpad site).

We therefore created a menu entry for Nemo under the Applications category of the Applications Menu through alacarte. But it did not show up there, nor in any other menu category of the Applications Menu. So we deleted it and tried again – same result.

Ultimately after several more tries followed by some more searching, it proved to be in the Other category of the Applications Menu, which itself on our systems is set as hidden because all useful entries there are already shown under other categories.

This placement in Other proved to be prescribed behaviour according to freedesktop.org, because that is the default placement if there is no "Categories=<>;" attribute in a .desktop file or if the value of the "Categories=<>;" attribute is not recognized. And alacarte does not write a "Categories=<>;" attribute, even if a new menu entry is created manually within a given menu category of the Applications Menu. And without that attribute, alacarte also does not allow drag+drop of the newly-created menu entry from Other to a more specific and appropriate Applications Menu category.

Hence the two issues raised, ie the one here and the one at https://bugs.launchpad.net/ubuntu/+source/alacarte/+bug/1245315). Specifically:

The manual entries were not potentially useful amended copies of .desktop entries already present at a higher level in the system directories. And the delete instruction was meant actually to delete them, not to hide them. Instead, they merely accumulated in /home/... as hidden.

Clearly therefore, as this instance demonstrates, a true delete function in alacarte of local (/home/...-based) .desktop files – in addition to hide – is useful.

It does not hurt, as a normal user without root privileges cannot add, change or delete any .desktop files outside of /home/... anyway. (And a user adopting root privileges should take responsibility for his own deeds.) Any superfluous .desktop files can only ever be created by the user through alacarte in /home/...

So, even with true delete functionality in alacarte, the .desktop entries present in the system dirs can only ever be hidden. And, as system and local .desktop files are inversely hierarchically merged to make up the Applications Menu as it appears on the desktop, they will always remain visible in alacarte but marked as hidden, as per menu specification.

And, as to the second issue, it would clearly be useful if alacarte could write the "Categories=<>;" attribute of .desktop files.

(We ultimately had to resort to manually editing the .desktop files to get the Nemo launchers in their proper category within the Applications Menu on our systems. But this we only could do with some confidence after studying the pertinent freedesktop.org specifications – not quite a recommended route for the average computer user.)

Either this could be automatic in alacarte, reflecting the Applications Menu category in which a menu entry is actually created or to which it is moved by drag+drop.

Alternatively, the Categories parameter could be presented to the user in the New Item dialog and in the Properties dialog in alacarte, for example with a drop-down list of available choices.

But of course, if, according to the menu specification, there is another mechanism for the user to determine into which menu category of the Applications Menu a menu entry is placed (see your reply to launchpad submission #1245315), then that is just as good. The only key thing is that, at present, the user has no control in the matter, except by manually editing configuration files.

I really apologize for the length of this comment, but I hope that it helps better to explain the motivation behind the two submissions.