menu editing

[Havoc Pennington]

On Tue, May 13, 2003 at 07:02:06PM +0530, Biju Chacko wrote: 
> I'm just wondering whether menu editing makes sense to individual users.
> >From a user perspective the system menu is a definitive listing of all
> available applications. Logically then, additions and deletions to the
> menu should be reflected by the underlying OS. That is, when I remove
> 'Foo' from the menu, package foo-1.2-3.rpm is uninstalled and vice
> versa.
> 
> Currently package management doesn't really fall into the scope of menu
> editing and I am not sure this is the right time to add it. 
> 
> So that just leaves rearrangement of items. That's something that can be
> accomodated by a separate user editable section that doesn't override
> the system menu.
> 
> Am I making any sense? I'm afraid I'm not as clear as I would like to
> be.
> 

In fact I think you're 100% right about that - you've more or less
explained how OS X works. See also my previous posts with extended
rants about how a menu of all apps is doomed, broken, and hosed from a
usability point of view.

In trying to design the UI for a Red Hat Linux package tool, we
realized that there were at least three implementation details 
users are currently forced to understand, rather than understanding 
simply "an application":
 - the RPM package (complete with unfriendly names and 
   lack of 1-1 mapping to applications)
 - the 'groups' in the comps file (Red Hat specific)
 - the .desktop file and "launchers"

Making the menus (or replacement) and application install/uninstall as
simple as OS X is a total nightmare due to this implementation
legacy. It could be done but it's a *lot* of work.

(Just replacing RPM and .desktop files with no back compat sounds
easy, but that's not an option.)

Anyway, this is more of a blue-sky problem to solve I think,
though I hope someone does figure it out.

Havoc