[kde-artists] Icon naming issue (was: KDE/kdesdk)

[James Richard Tyrer]

On Wednesday 25 April 2007, Jonathan Riddell wrote:
> SVN commit 658018 by jriddell:
>
> Move icons to oxygen namespace

This seems like a very poor idea.  Why do we keep making the same mistakes?

I would like to suggest a really radical solution.

	We put the HiColor icons in the "hicolor" directory

	We put the CrystalSVG icons in the "crystalsvg" directory

	We put the Oxygen icons in the "oxygen" directory.

To suggest anything else is insanity.

The problem is that we have already screwed things up and this situation 
is a perfect example of how kludges just keep getting worse -- they 
never improve.

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.

My suggestion, which should hold true even if you don't agree with how I 
would do things, (and which should be obvious) is that the answer to 
these issues will not be found by moving icons around and giving them 
names which don't correspond to their actual style.  The answer lies in 
the code.  Changes in code can redirect the search without moving the 
icons.  But it should NOT be hard coded as it is in our current release.

The icon search is supposed to fall back to HiColor.  The problem is 
that now neither KDE nor GNOME has a set of HiColor icons to fall back 
to.  The answer to this should be obvious (and it needs to be added to 
the standard).  We need to have a list of secondary backup icon themes 
that will be searched when a fall back to HiColor doesn't find an icon. 
  I suggest that this be in a file so that it can be easily changed (or 
changed by the user).

The current XDG standard allows this secondary list *before* HiColor but 
it does not specify how this is to be implemented.  We appear to have 
hard coded CrystalSVG before HiColor and this is a mess for anyone that 
doesn't use CrystalSVG.  This would also work if implemented with a 
configuration file since it could be changed to what I suggested by 
adding "hicolor" at the start of the list.  So, actually, we don't need 
to fall back to HiColor; what we need to do is to fall back to the list 
of fallback icons in a file as this will cover all contingencies.

-- 
JRT