Re: New file type handling

[Seth Nickell <snickell redhat com>]

> The new system allows you to set the system-wide handler for a file type
> from any file property box. Why on earth would setting a handler for
> "file1.png" set the default PNG handler for the entire system? That
> property box is the FILE's property box. Global config actions don't
> belong there, even if they're clearly labeled as such. 

Its not an ontology. Its a common design mistake to obsess too much over
categorization. Its much more important to orient interfaces toward the
most common tasks than to have clean categorization (esp. for relatively
infrequently used things like the file property box for which most
people are unlikely to develop a strong conceptual model).

> It seems to me that the file types capplet needed to be rethought and
> simplified, not eliminated.

The idea that a central file types capplet just "needed to be rethought
and simplified" had resulted in the capplet being redesigned /
reimplemented numerous times by talented people, with little or no
improvement (often regression). This suggested that there was something
wrong with the approach.

This is the central use case:
1) A user has a file and it opens with the wrong thing. They want to
change things so the file opens with something different. As the central
use case, the design should be shaped around this. Note that the user
has the file at hand when they encounter this problem, and hence already
has the information about the "type of the file they wish to change"
available. We shouldn't make them locate this information again. The
"find the right entry" problem is the bane of the central mime system.
Its simply not well suited to the task at hand.

Here are some infrequent use cases:
2) A user wants to run a command-line tool on a file, or (and this means
the GUI program is buggy) a GUI program that has not properly registered
itself with the file association system. This is handled directly with
"Open With...", or by "Adding" from the properties tab. Once again, this
should be rare if app developers do their jobs.

3) A user wants to take a new machine and configure all their file
associations in one go. Note that most people do *not* do this, but
configure things as they go along and notice file associations are not
as they prefer. This case might be a little slower without a central
dialog, but its fairly fringe, and its still reasonable (just go through
your documents folder, find one file of each type you're interested in,
and configure it).

> In my view, the capplet would ideally present a list of applications.
> Clicking an application would expand it and show a list of mime types
> the application can handle. If the application was the default handler
> for a type, the type would be presented in bold. Selecting a type and
> clicking a "Make this app the default handler for this type"  button
> would cause the selected application to become the default handler for
> the selected type. An "add handled type to this app" button would pop a
> dialog allowing the user to choose from a list of unhandled mime types
> or type a new one, thus specifying that the selected app can handle
> another type. An "Add application" button would do the obvious.
> 
> In this system, to change AppX to the default handler for FOO files, the
> user would open the capplet, click AppX, click the type, and click "Make
> default handler." Simple and intuitive, and we avoid digging through
> trees of mime types.

The central use case is "given a file of a certain type make the things
of that type open with PROGRAM" not "given PROGRAM set the file types it
opens". This design is exactly backwards for the central use case.

-Seth