mime-type icons, a proposal

[Frans Englich]

On Wednesday 06 October 2004 13:16, Jakub Steiner wrote:
> On Oct 5, 2004, at 12:40 AM, Ryan Gammon wrote:
> > People who want consistancy could go with the fdo-spec'd default.
> > People who are willing to give up some consistancy for style could go
> > for an icon theme.
>
> I don't see this argument very appealing. Let's make a spec that makes
> having consistent look easy, not hard. Perhaps there is a way order the
> lookup of a  mime type icon that does make app-defined mimetypes
> possible (although I'm not toally convince we really NEED this
> functionality still). For example:
>
> 1) check if there is a mimetype icon for the current default handler in
> the current theme
> 2) generic mimetype icon in the current theme
> 3) parent type (video/*, text/*) in the current theme
> 4) default handler mimetype in the inherited theme
> 5) generic mimetype icon in the inherited theme
> 6) parent type in the inherited theme
> 7) default handler icon in hicolor
> 8) generic mimetype in hicolor
> 9) parent type in hicolor
>
> This could give a consistent look even for fairly minimalist themes
> with only a handful of parent type icons.
>
> A single vanilla icon in a folder of distinctly different looking theme
> will just hit you in the face. And it's fairly impossible for theme
> authors to remain in sync when there is going to be not only new
> mimetypes showing up, but also new applications handling them. Even for
> a polished distribution - a user installs a new application and
> consistent look is history.

(not replying to your post in particular)

Perhaps this can be useful:

Assuming the priority is; 3rd party icons for mimetypes(hicolor) are only used 
when there isn't a specific mimetype icon in the theme, it means it will 
rarely happen. For example, all common specific-mimetypes would be covered by 
the icon theme since many people(probably the majority) needs them. For 
instance, icons for real media is already in the kde/gnome icon themes.

Depending on how one looks at it, it in turn means:

A: The theme consistency will only be broken for few users(those who install a 
3rd party app which adds an icon for a mimetype which isn't covered by the 
theme, such as probably an music editing or CAD program).

B: The advantages/disadvantages of having a 3rd party icon instead of the 
theme's generic mimetype icon, only applies for those who installs a 3rd 
party app.

Similarly, any conflict resolution would only take place when 1) an specific 
mimetype isn't covered by the icon theme; and 2) There is two or more 3rd 
party mimetypes with their own icons, installed.

This could be taken into account, if a conflict resolution is too performance 
heavy, or is tricky to specify in a clean way, because that conflict will not 
happen very often, AFAICT(which have failed before, otoh).


Two cents,

	Frans