Icon-mime type associations

[Thomas Leonard]

On Wed, Sep 22, 2004 at 11:15:25AM -0700, Rob Lanphier wrote:
> On Wed, 22 Sep 2004 18:38:25 +0100, Thomas Leonard
> <tal00r at ecs.soton.ac.uk> wrote:
> > This is the key decision to make. (2) is simpler for packaging, since
> > each app just drops its icon in a unique folder, although we'd have to
> > have so rules so that looking up the icon always got the same icon for
> > any particular set up (eg, sort the hicolor/* directories
> > alphabetically).
> 
> Actually, this isn't necessarily true.  It's possible to get package
> conflicts based on two packages trying to install the same file.

No, because they'd install to sub-directories named after the package
providing them (hicolor/gimp/mime-image:png.png vs
hicolor/eog/mime-image:png.png).

Do we have this problem with other systems which require installing files
into hicolor?

> > With (3), the icon will change when the user changes the default app.
> > If icons aren't app-specific, this means that the users see different
> > icons for their files, even though the files haven't changed. I think
> > this is confusing.
> 
> It's triggered by a user action, so I don't think it's too confusing. 
> Moreover, it's possible that the reason the user wanted to change the
> default program was because their chosen program has an interpretation
> of the file type which more closely aligns with their expectations.

You mean, if the default handler for foo.pot is open office, then it
should appear as a powerpoint presentation, but if it's emacs then it's a
translation file?

That works with a pure extension-based system, but not with MIME types (at
this stage, the file has already been identified as, eg,
"application/vnd.ms-powerpoint"), so all interpretations are going to be
similar.


-- 
Thomas Leonard			http://rox.sourceforge.net
tal at ecs.soton.ac.uk	        tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1