alacarte does not delete deleted application menu entries

[Leo H]

When a menu entry in the Applications Menu of Xubuntu is deleted using the Alacarte Menu Editor, then alacarte (3.10.0-1) does NOT delete its .desktop file. Instead alacarte writes a new "Hidden=true" line in its .desktop file in /home/<>/local/share/applications/ and it only deletes the entry from the list of menu entries which are shown in alacarte itself.

This is wrong. Delete and Hidden are two different things:

.desktop files with the attribute "Hidden=true" should be shown in alacarte as unticked menu entries.

Further, by failing actually to delete, alacarte populates /home/<>/local/share/applications/ with increasing numbers of obsolete and dysfunctional .desktop entries. These are difficult to identify and delete manually when browsing /home/<>/local/share/applications/, because alacarte gives all .desktop files which it makes non-specific generic names of the type alacarte-made-nn.desktop.

--
System: xubuntu 13.10 32-bit fully up-to-date

[Jasper St. Pierre (jstpierre)]

From the menu specification:

"Hidden should have been called Deleted. It means the user deleted (at his level) something that was present (at an upper level, e.g. in the system dirs). It's strictly equivalent to the .desktop file not existing at all, as far as that user is concerned. This can also be used to "uninstall" existing files (e.g. due to a renaming) - by letting make install install a file with Hidden=true in it. "

We show hidden entries because users may want to turn them back on, but the menu implementation should not show these.

Yes, the cluttering of alacarte-made-nn.desktop files is an issue. I'll look into solving it in the future by giving the files actually good names.

[Leo H (leo-h-hildebrandt)]

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 Applicat...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[André (truebix)]

I have just encountered this too. Before discovering https://bugs.launchpad.net/ubuntu/+source/alacarte/+bug/1241841 I was having trouble getting a icon to appear for the application. I would delete and recreate the entry (accumulating hidden duplicates) with no success. I would then attempt to create my own entry from scratch, which would never show up. It turns out that the hidden entries were preventing the manually created one from being displayed.