Re: MIME interface suggestions

[Gabriel Bauman <gabe bravenet com>]

On Wed, 2004-09-01 at 16:34 +0100, Gustavo J. A. M. Carneiro wrote:
> A Qua, 2004-09-01 às 15:39, Jerry Haltom escreveu:
> > I believe the thought process goes like this:
> > 
> > If the application the user wants to use is not listed in the menu, then
> > that application does not have a .desktop file, or it is misconfigured.
> > In which cases, it wouldn't appear in your application list dialog either.
> 
>   Now that's silly.  ghex should appear in the menu for _any_ file,
> because every file type is a subtype of application/octet-stream.  If
> you don't like that, uninstall ghex and the menu entry goes away.  It's
> as simple as that.

These are the kinds of problems I was beginning to foresee while
participating in the MIME-related thread of about a month ago. It comes
down to a lack of control.

At the end of the day, the user knows (or should be told in a central
location) what applications are available on their system, and what
capabilities those applications have. The user should then be able to
decide which apps they wish to see in their context menus, if any.

The fact that there are 22 applications on a system that can handle PNG
images does not mean that the user should need to pick between those 22
apps in a context menu.

Applications should register the types they can handle; The user should
be able to say "Make this application the default for all types it
supports" as well as "Handle this type with this application". Adding a
"Show this application in context menu" option in this central location
might also make sense.

I think driving thought behind the new MIME system seems like "assign
handlers to file types in as few clicks as possible". I believe it needs
to be "Let me view and manage how my desktop and associated applications
recognize and handle data of various types" instead. This should
encompass a) per-application registration of file types the application
can handle, b) per-file-type definition of possible file extensions, c)
per-file-type definition of sniffing rules and prioritization of said
rules d) per-file-type selection of default applications, and e) per-
file overriding of system default handler for file type, f) ability to
assign a default handler for a media type on a per-protocol basis.

Not all of this functionality needs to be exposed to the user, but the
supporting framework should be present. The BeOS did it right, back in
the day, and I'd love to see GNOME at least match it for usability.

-- 
Gabriel Bauman <gabe bravenet com>