xubuntu-dev team mailing list archive

[Leo H <1245300@xxxxxxxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of Xubuntu
Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1245300

Title:
  alacarte does not delete deleted application menu entries

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alacarte/+bug/1245300/+subscriptions