menu editor massively defective

Bug #111896 reported by Ryan Vickers on 2007-05-02
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Alacarte Menu Editor
alacarte (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

I've noticed that the "Edit Menus" Application for editing the menus (of course) has numerous, and, in my mind serious problems. For example:

1. It's extremely slow (and I have a fast computer with graphics acceleration enabled)
2. It doesn't work properly:
  -when you move items around they will rather not go, duplicate, or both (and more)
  -the new menu window always appears underneath (this one's not so serious)
3. It could be a lot easier to use and have more features
4. Did I mention it's very slow?

If possible, when this is fixed, could it be made a patch/update so people can get it without having to get another entire distro. version?

I've noticed this problem since 6.06 and it probably existed before that too. I'm thinking it would be good to integrate the edit menus option into the Add/Remove programs application (which is very nice by the way) In some way so you can pick as a new feature "remove" or something and maybe also "show similar programs" and "install selected" (out of list that would appear). I think this fix (when done) should come in with the updates in the update manager when they are released.

Jared Moore (cornflake-pirate) wrote :

I wouldn't say that it's "massively deficient", but it does have several serious bugs. Could you be more specific, e.g.

1) Which operations do you think are slow?
2) Would you be able to describe any more specific test cases? Several problems are already known.
3) How could it be easier to use? What extra features could it have?
4) Yes, you did :)

I'm not sure that integration with Add/Remove programs is such a good idea. Add/Remove programs is a user-friendly package manager, while Alacarte is a main menu editor... although they are vaguely related, I can't imagine a good way to put them together. After all, Unix is all about small specific programs doing one thing well :)

Thanks for responding - I know this is kinda old now, but it's still true in 7.10.

As for being extremely slow, the more programs you install, the more entries there are, and this seem to slow it down, a lot. could this be fixed some how? Furthermore,after adding a couple custom entries to the menu, say, 3, 4, 6, or more, just clicking the menu button on the panel for the first time after every logon takes a long time to load. Ah, Why??? I'm just kind of worked up a bout this because it's just such a fast efficient high-class operating system,you would not expect there to be major flaws like this menus in it still!

As for the moving of items, once you figure it out, it's not so bad, but it's still slow to do this, and it often will /still/ not work, or duplicate the launchers, etc.

As for the new window appearing /under/ the main window, why are we doing this now? Just to confuse people? I mean, I can find it because I actually check the window list but a lot of people will expect it to just open and show up, including me...
It doesn't seem to always do this, but most of the time... Now that I think about it, I think it's the desktop effects that cause it for some reason - another bug.

As for #3, fixing all these problems would make it easier to use, an could it possibly be a little better integrated with "Add/Remove", and really, just make it more snappy and responsive, and that would be such a big deal!!

Jared Moore (cornflake-pirate) wrote :

Thanks for providing more specifics. I'll have a look at what I can do. If you know how to program, I'd suggest you have a look at the source and see if you can solve some of these problems yourself :)

Regarding new windows coming up underneath - this has already been reported as a separate bug (

I'm not at all sure how to use this tool. Simply browsing to the app that I want to have THAT is usilng right click Applications tab then other add and browse to the program gives nothing, just a blank stare. In another case I created a which (without normal top line) point to that and have the shell point to the app in one case works It's really most annoying and costing a lot of time. I does not do what I would have expected. Half the time it just looks at you.

Daniel T Chen (crimsun) on 2008-10-08
Changed in alacarte:
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (

Changed in alacarte (Ubuntu):
importance: Undecided → Low
YannUbuntu (yannubuntu) wrote :
Changed in alacarte (Ubuntu):
importance: Low → Wishlist
status: Confirmed → Triaged
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
status: Triaged → Confirmed
status: Confirmed → Triaged
Changed in alacarte:
importance: Undecided → Unknown
status: New → Unknown
Antti Kaihola (akaihola) wrote :

The item duplication bug has a patch in the upstream bug tracker:

Changed in alacarte:
importance: Unknown → Wishlist
status: Unknown → New
quequotion (quequotion) wrote :
Download full text (3.4 KiB)

This is still a problem, even in Maverick Meerkat.

I'd like to make this a long list of feature requests rather than a bug report.

I've posted about this in the forums and in brainstorm.

There are two problems here:

1. The menu system itself is overcomplicated, very difficult to modify, and prone to mistakes (which users and even packagers often make).

2. Alacarte shows design flaws, not just bugs, but several misconceptions about how the menu works (not that it works well).

Let me explicate a bit further (although you could google my posts elsewhere for the same info).

The menu consists of several sets of text files in several locations both in user space and in the root filesystem. The files in userspace override those in the root filesystem, so you can redefine a menu on a per-user basis and maintain a system-default menu. That's almost a good idea, until an application is removed and the user menus don't change because the package manager has no idea they even exist due to lack of integration with dpkg (FEATURE REQUEST!).

Among these files, the three most significant are the ".desktop" and ".directory" and ".menu" files. These are all stored in separate locations, each of which is one big folder containing lots of uncategorised, little files (which makes obsessive-compulsives very, very angry).

".desktop" files, available in "~/.local/share/applications" (user), "/usr/share/applications" (root), and several other locations (separated for start-up items, screensavers, certain kde programs, etc) define targets to a specific place or program. They also (re)define mime-types associated with that program (which are also defined elsewhere and defined differently) and affect what you see (and don't see) in the "Open with..." dialogue. These files and their properties are not universally recognised (Firefox, for example, seems to have a totally different opinion about what programs are associated with what mime-types or if any association even exists)

".directory" files, available in "~/.local/share/desktop-directories" (user), and "/usr/share/desktop-directories" (root) define special properties for directory entries in a menu. Some of these are fun, like setting an icon for a sub-directory. Actually, that's about the most useful (possibly only) function they serve, as many of their properties can be defined in ".menu" files.

".menu" files, available in "~/.config/menus/" (user), "~/.config/menus/applications-merged/" (especially for wine's convoluted menus), "/etc/xdg/menus" (root), and "/etc/xdg/menus/applications-merged" (for some special cases like Gome Control Center) define the actual structure of the menu. They can be used to make explicit menus, by listing what directories and desktop shortcuts are to be included as well as implicit menus, by listing what categories of desktop shortcuts are to be included (the categories are defined in the ".desktop" files and consist of a somewhat standardised set of keywords mixed with whatever users and packagers can come up with). These also effectively create and give names to directories, meaning the basic functions of ".directory" files are redundant.

Alacarte inevitably fails to make...


quequotion (quequotion) wrote :

I forgot to mention Alacarte also fails, quite regularly, to copy all of the information from an original (root) ".desktop" file in to a new (user) ".desktop" file, resulting in programs losing their mime associations and multi-lingual names, etc. (alacarte almost always represents menu changes by creating new files to override the old ones)

It also makes ugly files with names like "alacarte-made~1.desktop" rather than keeping the name of the original file or appending a number to the original name of the file.

Alacarte also keeps a set of files to undo menu changes... these cannot be used by alacarte or any other program and have no meaning whatsoever....

Changed in alacarte:
status: New → Incomplete
Changed in alacarte:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.