[Nautilus-list] Proposed change in MIME capplet UI

["John Sullivan" <sullivan eazel com>]

Several of us were discussing some of the UI issues with GnomeVFS's "File
Types and Programs" capplet that lets users configure which
applications/viewers to use with which MIME types.

One of the behaviors inherited from this capplet's origins as a clone of the
old GMC "Mime Types" capplet is that the built-in information can be viewed,
and supplemented, but not removed. For instance, at the top level the
"Delete" button is only enabled when a user-added MIME type is selected. And
one level deeper, the user can add extensions to the list of extensions, or
remove extensions that they've added, but not remove any built-in
extensions.

I am not sure whether this was done originally for UI or implementation
reasons, or a combination of the two. As it stands, it is at least confusing
(there's no feedback as to why you can't delete certain items, and no way to
distinguish the ones you can delete from those you can't), and at worst
problem-causing (no way to fix mistakes in the built-in data: maybe some
extension is used by multiple unrelated programs and the built-in one isn't
the one you care about).

We're at the point in the implementation of the "File Types and Programs"
capplet where we have to either do a fair amount of work to make sure this
built-in-equals-unremovable behavior works, or do a fair amount of work to
eliminate this behavior.

I'm now proposing that we eliminate this behavior. Users will be able to
remove any of the built-in data through the capplet UI. Any such removals
will be stored in user-specific delta files without changing the built-in
system file. We'll provide a button in the capplet to reset all the settings
to the built-in version. (The implementation for this button will be to
delete the user-specific delta files.)

I'm posting this message to give people a chance to warn us of any terrible
consequences of this proposal. If nobody hollers, we'll probably start
making this change very soon. If people holler, we might make this change
anyway, but we'll at least discuss it more first.

Holler away if you are so inclined,

John