menu editing

[Mike Hearn]

> 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.

I'd note that the MacOS "native" approach to packaging and menus is
basically broken at this point - the last time I chatted to my local Mac
zealot about it he told me the majority of apps used some kind of
installer service nowadays - they don't even all use the provided Apple
installer, some of them use Wise which is a name familiar to many
ex-Windows users.

It's also not applicable to Linux, as todays filing system technology
can't cope with representing abstract things like dependancies. One
approach to this is shown at http://zero-install.sf.net, but I'm not
convinced it's workable in the real world yet.

> 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"

One problem is that often users (as in, real users) may wish to install
package that does not correlate cleanly to an application. Think themes,
think plugins, think documentation packs. And of course command line
programs. That's ignoring all the other things that are pulled in behind
the scenes.

> 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.

As already noted, if anything software management on OS X is now
fragmented rather than simple and consistant. AppFolders turned out to
be too limiting in the real world. Even Apple no longer use them.

Besides, there's no reason IMO an intuitive UI couldn't be placed on top
of this system. I've pondered it quite a bit - my favourite so far
(though it changes every other thursday) is the idea of dragging the
application [icon/launcher] out of a webpage [using a simple browser
plugin] and onto a panel, the desktop, the Applications/K menu or
whatever. What you're dragging is actually a .desktop file, but the user
doesn't need to know that. The icon goes gray until the package has
fully downloaded and resolved its dependencies behind the scenes, at
which point it lights up and clicking it starts the program. In terms of
effort I can't really imagine something more trivial than that other
than typing in the name.

If anything, that's simpler than on MacOS where you have to download
then open this magic DMG file-cum-folder which will even self destruct
in some circumstances to get the AppFolder if you're lucky or installer
program if you're not.

The main problem is that the launcher/.desktop abstraction, while
useful, leaks like a sieve at present. Things that don't install into
menus, the need to manually install things that aren't apps, that aren't
plugins, who knows what they are? The ability to use launchers is a rare
treat, if anything. Oh, and then don't forget that you can't uninstall
again from the GUI (or at least redhat don't appear to provide an UI for
this).

Everybody is still figuring out how to make large menus packed with
stuff the user has never seen before friendly. It's not easy, if I
hadn't read the specs I still wouldn't really fathom what makes a
software "more software" or less. But, we don't have much choice. Linux
isn't MacOS or Windows, it comes loaded with almost everything the user
might need.

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

Any replacement would have to do what RPM and .desktop files do today
just as well.... and I've tried really hard, but couldn't come up with
anything that would do all the things we need them to do, but remain
simple.

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

I think everybody shares that sentiment. For now, self-organising menus
are useful, especially considering that with stuff like apt installing
software is far easier than on any other OS (when it works) - having to
manually arrange menus myself is a boring task that I'm glad we're
leaving behind. 

thanks -mike