[kde-artists] Icon naming issue (was: KDE/kdesdk)
James Richard Tyrer
tyrerj at acm.org
Fri Apr 27 04:49:48 BST 2007
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
______________________________________________________________________________
kde-artists at kde.org | https://mail.kde.org/mailman/listinfo/kde-artists
More information about the kde-core-devel
mailing list