mime-type icons, a proposal

[Ryan Gammon]

Frans Englich wrote:

>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
>>    
>>

Get rid of check 8 and I think we're on the same page. Stating the 
obvious, this doesn't guarantee a consistant look and feel, as hicolor 
may not match any of the themes, or even each other. I have no problem 
with this, but was pointing out that if the style of hicolor was spec'd, 
at least asthetically sensitive users could have one theme where the 
icons were guaranteed to match.

I like what Frans is saying below -- makes sense to me.

>>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
>
>_______________________________________________
>xdg mailing list
>xdg at freedesktop.org
>http://freedesktop.org/mailman/listinfo/xdg
>
>  
>


-- 
Ryan Gammon
rgammon at real.com
Developer for Helix Player
https://player.helixcommunity.org