Re: [Usability] An extended default applications dialog

[Christian Neumair <chris gnome-de org>]

Am Sonntag, den 14.01.2007, 12:58 +0000 schrieb Matt Medland:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Christian Neumair wrote:
> > Am Samstag, den 13.01.2007, 11:59 +0100 schrieb Christian Neumair:
> >> Am Donnerstag, den 11.01.2007, 20:50 +0000 schrieb Matt Medland:
> >>> I'm proposing that mime-type association be centralised in the
> >>> Preferences>Preferred Applications area, since that seems the natural
> >>> place that anyone would go to. This would, potentially, be useful for
> >>> everyone.
> >>>
> >>> The spec is here:
> >>>
> >>> https://blueprints.launchpad.net/ubuntu/+spec/enhanced-preferred-apps
> >>>
> >>> and any comments or criticism would be appreciated.
> >> I'm extremely in favor of the "MIME type categories" proposed in some
> >> comments on the spec page, i.e. we'd have certain categories like
> >> "Audio", "Images", "Plain Text", "Text Documents", "Spreadsheet" etc.
> >>
> >> Each category would provide a listing of MIME types that each
> >> application has to support to be elegible for that category.
> >>
> >> The GUI must also allow to determine exceptions for particular MIME
> >> types that are part of the category, else we're not flexible enough to
> >> deal the requirements with specialized setups. The specialized MIME
> >> selection allows to select all applications that can be used for the
> >> MIME type in question.
> > 
> > This is what I have in mind technically:
> > 
> > The idea is to get rid of many of the "defaults.list" entries
> > (/usr/share/applications/defaults.list), and associate category
> > information with each MIME type. Applications could then register
> > against categories, and are just stored in defaults.list (i.e. against
> > special MIME types) when they are specialized or override the default
> > handler. Specialized applications would for instance be your favorite
> > Macromedia Flash Image Extraction Frobnicator.
> > 
> > I'm currently hard-coding categories and MIME types in a python script,
> > but we might end up with .desktop files that contain:
> > 
> > [Category]
> > DisplayName=Foo
> > Name=foo
> > MimeTypes=foo/bar;...;
> > 
> > Note that we'd standardize the valid "Name" fields.
> > 
> > 
> > 
> > I'm attaching a little not yet demo application I wrote in python that
> > can be used to play with the GUI. You can easily download it and run it.
> > 
> > * Pro: Simple default application selection
> > 
> > * Con: Many MIME types per category would make the "Details" entry very
> > long. Either use a specialized dialog, or just list exceptions.
> > Exceptions have the advantage that they do not list duplicate
> > information.
> > 
> > * Con: We use a combo box cell renderer in the tree view. Users might
> > not be used to it.
> > 
> > * Con: The current layout will make it impossible to have many MIME
> > categories although it looks good. We'll hopefully find a solution,
> > either tab based, or by having a layout like
> > 
> > 
> > Default Foo Application:    [ Application Combo ] [ Details ]
> > Default Bar Application:    [ Application Combo ] [ Details ]
> > Default FooBar Application: [ Application Combo ] [ Details ]
> > 
> > 
> > Please run the attached python script and give some feedback! :)
> > 
> > 
> 
> Wow, I can tell that you've put lots of effort into this. :)
> 
> I really like your script, maybe you could put a scrollbar on the side
> so that we could have more categories. Would there be anyway to only
> allow one drop-down thing to be open at a time?
> 
> I think that that gui would work really well once the few small teething
> problems have been ironed out and it's been jazzed up a bit with some icons.
> 
> Do you mind if I upload this to the bazaar branch that's attached to the
> spec?

No, of course not (license: GPL or PD at your opinion); but I'm
currently doing another implementation that is very similar to what I
proposed above, i.e. it will only have a few toggles in the main dialog
and a for each category a details dialog.

-- 
Christian Neumair <chris gnome-de org>