[kde-artists] Icon naming issue

James Richard Tyrer tyrerj at acm.org
Fri Apr 27 21:50:51 BST 2007


Kenneth Wimer wrote:
> On Friday 27 April 2007 21:58:27 Kenneth Wimer wrote:
>> On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote:
>>> Patryk Zawadzki wrote:
>>>> On 4/27/07, James Richard Tyrer <tyrerj at acm.org> wrote:
>>>>> As I see it, the problem is that we don't have a proper set of
>>>>> HiColor icons.  Someone moved all the existing HiColor icons to
>>>>> KDEClassic and for some reason all new HiColor icons were removed.
>>>>>  Then some HiColor icons were renamed CrystalSVG and some
>>>>> CrystalSVG icons were renamed HiColor.  Now GNOME seems to have
>>>>> emulated us and removed their HiColor icons as well.  To me this is
>>>>> a real mess.
>>>> Why is this bad? Apps drop their default icons to hicolor so these
>>>> are picked up regardless of the theme in use.
>>> HiColor is not "default", it is fallback.
>> Semantics
>>
>>>> Why should any theme put its icons there? If a theme is complete, no
>>>>  icons will ever need to be searched for in hicolor. If it is not
>>>> complete, it should provide its own list of parent themes (e.g.
>>>> "based on CrystalSVG") and the missing icons should be picked from
>>>> the parent theme, so again, no need to search hicolor.
>>> While I half agree with you, the point here is the standard:
>> Again, semantics...
>>
>>> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.h
>>> tm l
> 
> Sorry for saying this was a case of misunderstanding, it is not...as you 
> mentioned in this link the spec says:
> 
> ' In order to have a place for third party applications to install their icons 
> there should always exist a theme called "hicolor" '
> 
> I am not sure how you interpret this to mean that hicolor should be a full 
> icon theme on it's own.

DUH!

What I said in the past was based on what the spec said in the past.
<q>
It is recommended that the icons installed in the hicolor theme look 
neutral, since it is a fallback theme that will be used in combination 
with some very different looking themes.
</q>

The rest of my reasoning was based on simple logic.  If a "fallback" 
theme is to be used as such, then it must be a full icon theme or there 
won't be anything to fallback to.

If HiColor isn't to be a full icon theme (the spec has now been changed 
and so be it) then there must be a way for the icon search to fall back 
to something appropriate.  I note that if the bugs in the icon search 
are fixed so that it conforms to the spec that this will not be as 
important an issue.  But, there are still users that will install an 
icon theme other than Oxygen (one of the Crystal based themes, for 
example) and will not want to fall back to Oxygen.  All I am suggesting 
is that this should be configurable using the Control Center the same as 
everything else.

If the bugs are fixed and things are fully configurable, there is 
nothing to discuss except for the need for a new generic icon theme to 
replace KDEClassic.

-- 
JRT



More information about the kde-core-devel mailing list