Re: New file type handling

[Gabriel Bauman <gabe bravenet com>]

Hi, Seth, thanks for your detailed response.

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

I understand the argument you are making, and I'm not one of those
'purity of concept over real-world utility' people - still, I am not
convinced. 

Given Nautilus's recent strides towards a 'spatial' model ("the folder
window IS the folder!") it would seem to me that clean categorization of
functionality is paramount in this case. After all, if I open a file's
properties and delete the file, the properties window vanishes. That
says to me that things in that window affect only that file. This is the
kind of "strong conceptual model" that the spatial model depends on, and
I don't think it unlikely at all that people will expect consistent
behaviour from file property dialogs. Indeed, I have asked a couple of
other Gnome users in the office what they think of the change - they
found it jarring, as did I. They also missed the ability to assign a
handler for an individual file.

I see no problem with perhaps having a *shortcut* to a file types
capplet in the property dialog. Why not have a property page called
'Handlers' with something like "This file will be handled by the default
handler for 'PNG Images', 'Eye of Gnome' [Set Default Handler For PNG
Images] [Set Default Handler for This File]", where the first button
launches a system file handler capplet (selecting the correct type and
perhaps hiding the big scary type list) and the second launches a list
of applications known to provide support for the type? This would give
us the best of both worlds.

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

I don't think there was anything wrong with the approach of having a
central file type capplet. All of the implementations I have seen
suffered from the same trouble - too much (scary, verbose) information
visible, and no hint as to what you could actually do with it or what
you were affecting. Most every other major desktop OS has some kind of
central file type control panel - that says a lot for the approach.

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

Yes, you're right about that, I should have thought it through better. I
still think that the second use case should be considered, though. It
would be nice to have two tabs in a central file type capplet - one with
one of those cases, one with the other.

-- 
Gabriel Bauman <gabe bravenet com>