[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-artists
Subject:    Re: [kde-artists] Bug 163311
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2008-07-06 23:08:11
Message-ID: 4871505B.6060207 () acm ! org
[Download RAW message or body]

Kenneth Wimer wrote:
> On Sunday 06 July 2008 06:25:46 James Richard Tyrer wrote:
>> Oswald Buddenhagen wrote:
>>> On Sat, Jun 28, 2008 at 01:00:18PM -0700, James Richard Tyrer wrote:
>>>> Icons should not be moved around to address this issue -- doing so
>>>> is a kludge.
>>> oh, that issue, right. from previous discussions you should know that
>>> i agree with you on that point ... but, well, those who do the work
>>> can f**k themselves as much as they feel like. who cares - the users
>>> shouldn't notice much of that (of course they will notice some, as
>>> moving hundreds of icons never goes without mistakes. but who are we
>>> to dictate efficient processes to artists?)
>> So, how do we get the code to do this rather than having to move the
>> icons around.
>>
>> Note: it appears that the solution in GNOME is that apps install actual
>> HiColor icons in 'hicolor'.  But, KDE4 has apps install Oxygen in
>> 'hicolor'.  It works, but it needs to be improved (i.e. fixed).
> 
> Wrong, in Gnome the apps install Gnome icons in hicolor. Gnome icons are based 
> on the Tango style. There is no definition of a hicolor icon style and there 
> never will be so this argument is senseless. If KDE decides to use Oxygen as 
> their base style then those icons belong in hicolor.

I think that I said 'appears'.  The Gnome icon theme is basically a 
generic or neutral one and although some of the icons such as the 
folders do have distinctive style elements, many of them don't have 
anything that indicates what style they are.  Or, is this a distinction 
without a difference?  Does GNOME simply call its generic icon theme 
"Gnome"?

IAC, there is nothing distinctive or highly styled about the 'Gnome' 
icon them, which is the point.  It doesn't matter if it is called 
"hicolor.gnome" or simply "gnome".  GNOME used to install those icons as 
HiColor, but as I pointed out, with the common icon names, that won't 
work any longer.

> There is no such thing as a style-less style. We've had this discussion before 
> as well.

It appears that I did not succeed in explaining the issues to you very 
well since you still focus on a minor point.

The point of that discussion was what the spec said.  The issue with the 
spec has now been fixed.  It now uses the word 'neutral' rather than 
'un-themed'.  While I think that 'generic' is also a good description, 
there clearly can be neutral/generic style (isn't this the case with 
business clothing?).

We now have the Tango icon theme so there is really no need for a 
HiColor icon theme although I would have rather called it HiColor.  It 
doesn't really matter what the names are as long is there is some way to 
configure where the icon loader looks for icons.  Using "Inherits=" in 
the "index.theme" file for this doesn't work well.  The fact that 
HiColor has been changed from a theme to an empty name space means that 
the fallback to HiColor isn't going to find an icon in many cases.  So, 
we need additional fallback *after* HiColor (not before).  IMHO, this 
needs to be configurable -- fallback before HiColor causes problems.

Note that KDE doesn't not have a current generic or neutral icon theme. 
  That remains an issue.  What it should be called is only a secondary 
issue of little importance although the Icon Loader code could probably 
directly deal with names such as "hicolor.kde" a configuration file can 
address that.

Time has resolved other issues.  Not as well as if it had been designed, 
but it will work.  There still appears to be a small chance that 
multiple icons with the same name will be installed to 'hicolor'.  Not 
sure if that will happen.

-- 
JRT
______________________________________________________________________________
kde-artists@kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists
[prev in list] [next in list] [prev in thread] [next in thread]