Icon-mime type associations

Frans Englich frans.englich at telia.com
Fri Sep 17 02:54:15 EEST 2004


On Thursday 16 September 2004 23:29, you wrote:
> * Ryan Gammon <rgammon at real.com> [Sep 17. 2004 01:01]:
> > Frans Englich wrote:
> > >On Thursday 16 September 2004 01:48, Ryan Gammon wrote:
> > >
> > >A common use of mimetype icons is to follow up the document/context
> > >centric model; an icon tries to resemble what it represents as close as
> > >possible in order to make the user's association steps as short as
> > >possible. Functional names is another example. If cases like this(3rd
> > >party branding, I guess) is the major reason for the usage of such an
> > >mechanism, it would be a step backwards in terms of usability, AFAICT.
> >
> > I think it's a step forwards.
> >
> > Let's say the desktop alone controls document icons. I'd argue that
> > there's no way the desktop can both know about all media types, and have
> > icons representing all of them. New types get introduced all the time,
> > not all icon theme maintainers have the time to write icons for all
> > document types, etc.
> >
> > If the icon theme does not have a suitable icon, there are two things
> > the desktop could do:
> > - Show a generic file icon
> > - Let the app provide an icon
> >
> > If we show the user a generic icon, it provides no information to the
> > user.
> >
> > If we show a vendor-provided document, that at least tells the user
> > "this is content I can play with the Helix Player." They can recognise
> > that this file is a media file, and that it will open in Helix Player. I
> > think this is a step forward.
> >
> > Now, the vendor icon is a neutral hicolor icon, so it might not match
> > the surrounding icons, but that's more of a "should hicolor exist" kind
> > of argument. It seems to have been decided that hicolor is a good idea,
> > much to our satisfaction, or we'd be stuck trying to provide individual
> > icons for every icon theme -- not practical.
>
> I guess you don't have this problem in KDE. AFAIK KDE does mimetyle
> handling pretty conservatively with a very liberal amount of
> "changeability". Are we only talking about gnome here? Since everyting
> is about "hicolor" icons I wonder......is this a problem for freedesktop
> or gnome?

There's a lot of confusion about hicolor, and perhaps I know only adds to it: 
hicolor is basically a namespace which 3rd parties should install into, 
quoting the spec:

"In order to have a place for third party applications to install their icons 
there should always exist a theme called "hicolor"[1]. The data for the 
hicolor theme is availible for download at: 
http://www.freedesktop.org/software/icon-theme/. Implementations are required 
to look in the "hicolor" theme if an icon was not found in the current theme. 
"

KDE then happens to have a theme called "hicolor".


Cheers,

		Frans



More information about the xdg mailing list