quequotion
August 7th, 2010, 01:50 PM
Can we simplify this crazy menu system?
The ubuntu (gnome?) menu system as I've come to understand it:
.desktop files profile individual menu entries including icons, multilingual naming, command, etc. These are a good idea, but alacarte is a terrible manager for them. They also include a "categories" property which can be used to place shortcuts in various submenus that interacts with .menu files.
.directory files profile individual directory entries, the same way .desktop files profile individual menu entries. You can do some cool stuff with these, like give each submenu it's own icon.
.menu files arrange .desktop files and .directory files into an actual menu. These menus can be made by arrangement of categories or specifying which entries you want in a menu.
files in the users home directory override files in the system directories, there are at least six different locations, three for system-wide and three for each user, with these files but there may be others involved as well...
The .desktop files used for shortcuts also make their way into the "Choose program.." dialogue when opening a file. Since alacarte "edits" menu entries by creating a new, half baked, file the list of available programs gets duplicates, and even quadruplicates of applications whenever a user tries to make changes the "easy" way.
I've literally spent hours editing the .desktop, .menu, and .directory text files--rebuilding and reorganizing my menus to recover lost shortcuts, remove duplicate entries, put things in an appropriate category, and hide meaningless shortcuts after using alacarte.
Alacarte doesn't handle these files properly. I'm not sure it handles .directory or .menu files at all.
I understand the need for modular systems with interworking parts, but there has to be a better way to build this menu trap.
The ubuntu (gnome?) menu system as I've come to understand it:
.desktop files profile individual menu entries including icons, multilingual naming, command, etc. These are a good idea, but alacarte is a terrible manager for them. They also include a "categories" property which can be used to place shortcuts in various submenus that interacts with .menu files.
.directory files profile individual directory entries, the same way .desktop files profile individual menu entries. You can do some cool stuff with these, like give each submenu it's own icon.
.menu files arrange .desktop files and .directory files into an actual menu. These menus can be made by arrangement of categories or specifying which entries you want in a menu.
files in the users home directory override files in the system directories, there are at least six different locations, three for system-wide and three for each user, with these files but there may be others involved as well...
The .desktop files used for shortcuts also make their way into the "Choose program.." dialogue when opening a file. Since alacarte "edits" menu entries by creating a new, half baked, file the list of available programs gets duplicates, and even quadruplicates of applications whenever a user tries to make changes the "easy" way.
I've literally spent hours editing the .desktop, .menu, and .directory text files--rebuilding and reorganizing my menus to recover lost shortcuts, remove duplicate entries, put things in an appropriate category, and hide meaningless shortcuts after using alacarte.
Alacarte doesn't handle these files properly. I'm not sure it handles .directory or .menu files at all.
I understand the need for modular systems with interworking parts, but there has to be a better way to build this menu trap.