[ ... snip ... ] For end-user apps (i.e. those in the menus), it will almost always be desirable to maintain a 1 .desktop file to 1 RPM mapping. And in fact we should be syncing the name of the package displayed in the package tool (including translations) with the .desktop file name. Or even making package management happen in terms of .desktop files. From a single-user standpoint, "menu editing" (at least in terms of add/remove items) and "package management" really have no reason to be different.
I can't agree more with you on that, specially w/ the last sentence.
It would be a much more clear 'metaphor' for the newbie.
I've never tried a Mac on my life, but I believe that there is in Mac OS a kind of vFolder where all the applications reside, moving an installer there installs the application, removing the application from there uninstalls it (please correct me if I'm wrong).
Anyway, I think a strong relationship between Menu Items and Applications is a big step in usability... It would be very intuitive for a new user to drag an RPM to the menu, and have the application installed.
But I can't figure out how we can deal with a multiple-user desktop... should the new added RPM appear auto magically in all the other users' menus? Should the system alert the other users in the next login about a recently added application, and ask them if they want to use it? (i.e. put it in the menu)
What it's clear is that for desktop-apps it has no sense to have the app installed without the matching menu entry somewhere.
Just some brainstorm ideas.
Same here ;)
-- Mariano
