alacarte fails to write a proper "Categories=<>;" line to .desktop files

[Leo H]

When creating a new menu entry in the Applications Menu of Xubuntu using the Alacarte Menu Editor (alacarte 3.10.0-1) then alacarte does not enable the writing of a "Categories=<>;" attribute in the new .desktop file created in /home/<>/local/share/applications/.

Without a recognized and meaningful "Categories=<>;" attribute, the new menu entry is relegated by default to the non-specific "Other" menu category in the Applications Menu of Xubuntu.

Moving the newly-created menu entry in question to a more meaningful Applications Menu category (such as, eg, "Applications", "Office", "Systems", etc) by dragging and dropping then fails in alacarte due to the very absence of any "Categories=<>;" attribute in the .desktop file.

Instead,

First, when creating a new menu entry in, for example, "Applications", then alacarte should write a corresponding "Categories=<>;" attribute line in the newly-made .desktop file.

Second, when dragging and dropping the newly-created menu entry in alacarte from, for example, "Applications" to, for instance, "System", then alacarte should amend the "Categories=<>;" attribute line in the .desktop file accordingly.

Note 1: If alacarte cannot do these things automatically, then it should at least allow the user to choose the Application Menu category, say, from a drop-down list, when creating or editing a menu entry, and write this choice to the corresponding .desktop file in the form of a suitable "Categories=<>;" attribute line.

Note 2: Resolving this issue by manually editing .desktop files, of course, wholly defeats the very raison d'être of Menu Editor programs such as alacarte.

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

[Esteban Mora (esteban1972)]

I can confirm that this bug exists. :-S

[Jasper St. Pierre (jstpierre)]

The "Categories" field is only one way that the menu specification decide what subfolder of the menu it will end up with. The menu spec says that ~/.config/menus/applications.menu is what decides where menus go.

Alacarte is a menu spec compliant editor. If XFCE does not respect the menu spec, it's their bug.

[Leo H (leo-h-hildebrandt)]

This issue finds its roots in a problem with the creation and deletion of Applications Menu (aka Main Menu) entries which is explained on:

https://bugs.launchpad.net/ubuntu/+source/alacarte/+bug/1245300

Comment #2 there explains the motivation for the present submission in greater detail. It appears not related or limited just to Xfce.

Specifically, the key issue of the present submission centres on giving the user GUI-based full control through alacarte to configure the desired allocation of individual menu entries (launchers) to the Application Menu categories. At present, this can only be fully achieved by manually editing .desktop configuration files.

Note: Clearly, there is no intention (nor any need) to deviate from the standard menu specifications. It is merely a matter of fully enabling what goes where in the Applications Menu across (as opposed to within) the various menu categories under GUI-based user control.

[Launchpad Janitor (janitor)]

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

[Donjan Rodic (bryonak)]

Same with Ubuntu 13.10 64bit upgraded from 13.04.
Editing the menus in gnome-panel or alternative application launchers/applets doesn't work as well as it should. There is no easy and obvious way (e.g. just drag&drop) to move the unnecessarily spammy new categories (Sundry, System Settings separate from System Tools, lots of items in Other) into one consolidated menu directory. But I guess that's another bug report.

[Jasper St. Pierre (jstpierre)]

Again, the Categories=<>; key is not what decides what apps go where, according to the menu-spec.

Alacarte writes to ~/.config/menus/applications.menu or similar, which should describe any user-configured overrides to the menus. If XFCE's menu implementation does not support this format, then it is not a menu-spec-compliant menu, and alacarte shouldn't be used to configure it.

You can see this file for yourself (it may also be ~/.config/menus/xfce-applications.menu -- check $XDG_MENU_PREFIX), and look at the customizations alacarte is writing to your applications.menu file.

I tested this with gnome-panel and gnome-shell, both of which use the gnome-menus library, and Alacarte's customizations came through fine for me.

[Esteban Mora (esteban1972)]

Hi,

I downloaded alacarte 3.6.1-0 from http://packages.ubuntu.com/raring/all/alacarte/download. Then remove alacarte 3.10 from my Xubuntu 13.10 using Synaptic. Then, using GDebi, I installed the 3.6.1 release. And finally, I used Synaptic again to block alacarte from upgrading. Since there is no fix yet for the package, this "solution" works fine. ;-)

[Dan Bryant (justdan96)]

I can confirm the same behaviour (new items appear in "Other") on Fedora 20 with XFCE4:

xfce4-panel-4.10.1-3.fc20.x86_64
alacarte-3.10.0-1.fc20.noarch
gnome-menus-3.10.1-1.fc20.x86_64

The trouble I am having is that the .desktop file is created by alacarte but the ~/.config/menus/xfce-applications.menu file does not seem to be updated in the way I would expect. For instance I create a new Item in the Games menu in alacarte, the generated .desktop file looks like this:

cat ~/.local/share/applications/alacarte-made-1.desktop
[Desktop Entry]
Comment=fheroes2
Terminal=false
Name=HOMM2
Exec=/home/dan/Games/fheroes2/fheroes2.x86_64
Type=Application
Icon=/home/dan/Games/fheroes2/image/fheroes2_32x32.png

Which is all correct, but I don't see an entry in xfce-applications.menu:
        <Menu>
                <Name>Games</Name>
                <Directory>xfce-games.directory</Directory>
                <Include>
                        <Category>Game</Category>
                </Include>
        </Menu>

If I manually edit the file I can add in the .desktop entry and it will appear in the Games menu correctly:
        <Menu>
                <Name>Games</Name>
                <Directory>xfce-games.directory</Directory>
                <Include>
                        <Category>Game</Category>
                        <Filename>alacarte-made-1.desktop</Filename>
                </Include>
        </Menu>

I hope the above explanation is clear as this behaviour is a bit puzzling to me.

[Dan Bryant (justdan96)]

I have just upgraded to alacarte-3.11.91-1.fc21 (installed locally by downloading the RPM from the Rawhide repository) and the issue is now fixed. It seems the solution is just to update alacarte to the latest version. From the alacarte 3.11.91 changelog:

Changes:
 Drop Help button
 Ensure items have valid Exec
 Add a man page
 Make Restore button work again
 Fix createing menus
 Fix creating items