Icon-mime type associations

Rob Lanphier robla at real.com
Wed Sep 22 21:15:25 EEST 2004


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.

> I think icons shouldn't be program-specific, except for native
> formats.  Eg, image/png shouldn't have a gimp logo on it just because
> gimp provided the icon, while image/x-xcf (Gimp's native format)
> should have a gimp logo on it, even if eog provides it.
> 
> 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.

I would think it'd be more confusing to the user to have the icon change
because of an application installation, even in cases where the
application isn't configured as the default for a particular media
type.  Right now, there's not a lot of commercial ISVs developing
software for the Linux desktop (relative to Windows), so the strains of
not having clear rules for quiet coexistence haven't been felt. 
However, commercial ISVs are VERY particular about their branding, and
will not hesitate to stomp over other icon installations if no clear
rules are established up front.

Rob

-- 
Rob Lanphier, Development Support Manager - RealNetworks
Helix Community: http://helixcommunity.org 
Development Support:
http://www.realnetworks.com/products/support/devsupport




More information about the xdg mailing list