mime-type icons, a proposal

[Frans Englich]

On Friday 01 October 2004 22:53, Ryan Gammon wrote:
> Alexander Larsson wrote:
> >On Wed, 2004-09-29 at 11:03 -0700, Ryan Gammon wrote:
> >>>>It looks to me like the mac actually will change document icons based
> >>>>on the explicitly specified user preference, and even goes beyond this.
> >
> >I'm not sure what to think about this.
> >On one side, it *does* give you better hints on what will happen when
> >you click on it. But on the other hand its very app-centric, which some
> >people think is wors, and it sometimes makes it hard to tell what sort
> >of file it is. (For instance, the real icon doesn't have the "mp3" text
> >on it, so you probably can't tell it appart from a wav or realaudio
> >file.)
> >
> >These are essentially two different approaches, app-centric and
> >document-type-centric. I think we'll find it hard to reach consensus on
> >one of them on this list. So perhaps we should make the system allow
> >both somehow and leave this up to the desktops?
>
> I agree.
>
> IMO, our problem is that what we have right now in hicolor is basically
> an app-centric model that doesn't work due to file name conflicts.
>
> If a desktop environment decides it wants to be "document centric", it
> should be saying that apps can't influence icons, even by putting them
> in hicolor. Fallback icons installed by an app are inherently app-specific.
>
> If the desktop environment decides to be "app-centric", it should go all
> the way and provide an icon conflict resolution system that can figure
> out the appropriate icon.
>
> Document-centric ui's are going to be fine for the main popular apps --
> those apps can work with the theme & distro providers to make sure their
> icons are covered with the theme/distro.

But here's the assumption that there /is/ an interest of being application 
specific -- namely the main popular ones, and that they are given the upper 
hand, compared to small apps. To me, it's still unclear /why/ it is at all of 
interest, and why it hence can be assumed. We talk about being app-centric, 
but it's not the desktop environments, or the users who push it.

However, I don't see what would be wrong with this priority:

1. If exact-mimetype&icon exists in theme/system, use it
2. If application-installed exact-mimetype&icon exists(hicolor), use it
3. Fallback to generic/category mimetype in theme

In this way themes and applications have equal influence, But, the theme(the 
the user) have the upper hand when conflicts emerges. In this way the /user/ 
is always in charge if he/she wants to; if there's no specific icon/mimetype 
installed by the system, the applications gets the chance. 

The result is that basic usages aren't disturbed(the usual big app breaks 
setup), but rare mimetypes and "small" applications still gets influence. 
This is also likely to be explicitly wanted by the user, since the usage 
scenario wasn't thought of before, but was introduced with that rare app.

But I'm almost 100% sure Alexander proposed this before. I tried to find it to 
see why it got shot down, by technical issues, for example(performance in 
lookup?). In that case, sorry for the noise.


Cheers,

		Frans