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 proper .desktop, .directory, and/or .menu files to reflect changes and thus fails to make proper changes and/or puts menu (items) in strange places, duplicates them, and/or makes them disappear. Also, changes in Alacarte have no relevance to dpkg, so when programs are removed or changed, changed or altered menus are not.
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/applicati ons" (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/applicati ons-merged/ " (especially for wine's convoluted menus), "/etc/xdg/menus" (root), and "/etc/xdg/ menus/applicati ons-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 proper .desktop, .directory, and/or .menu files to reflect changes and thus fails to make proper changes and/or puts menu (items) in strange places, duplicates them, and/or makes them disappear. Also, changes in Alacarte have no relevance to dpkg, so when programs are removed or changed, changed or altered menus are not.