Icon theme spec & inheritance

[James Richard Tyrer]

Shaun McCance wrote:
> On Mon, 2007-06-18 at 17:35 +0200, Oswald Buddenhagen wrote:
>> On Sun, Jun 17, 2007 at 05:56:52PM -0700, James Richard Tyrer wrote:
>>> Aaron J. Seigo wrote:
>>>> On Sunday 03 June 2007, James Richard Tyrer wrote:
>>>>>  As you said, HiColor needs to inherit KDEClassic, but in GNOME,
>>>>>  HiColor probably needs to inherit Gnome.
>>>> it doesn't.
>>> What doesn't do what?
>>>
>> oh, c'mon, it's clear that this referred to the last sentence. you are
>> unable to state a problem in a few words and aaron is unable to
>> split/cut quotes - so what? ;)
>>
>> this is my summary of the topic. there are three categories of icons
>> that need to be considered separately:
>> - generic icons
> 
> [snip]
> 
>> - application menu icons
>>   - consensus seems to be that every application *has* to ship a hicolor
>>     icon. yes, even if it is part of a desktop's core module. an
>>     application that does not provide an icon here does not deserve
>>     better than being shown as a question mark
> 
> When did that consensus come about?  Any application that just
> uses an icon from Table 2: Standard Application Icons in
> 
> http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
> 
> should not be required to ship its own icon.  In fact, they should
> not ship their own version.  Otherwise, Yelp and khelpcenter will
> both try to install
> 
> /usr/share/icons/hicolor/apps/32x32/help-browser.png
> 
> And that would be bad.

I think that the point was that the icons shipped by the application 
must be HiColor (and then optionally additional themes in addition to 
HiColor), not that the application was required to ship an icon.

-- 
JRT