[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-06-28 20:00:18
Message-ID: 48669852.80009 () acm ! org
[Download RAW message or body]

Oswald Buddenhagen wrote:

> i now took the time to look at it. you are wrong. comment #3 is 
> dead-on. of course that means that the standard basically prescribes 
> a colorful mix of icons from different themes.
> 
While Rex's analysis is correct *now*; what he correctly describes as a
bug was not considered a bug before KDE4 existed.  In fact, it was
considered acceptable practice.  But, he is correct, it has always been
KDE policy that an app should provide a HiColor icon for the menu.

Also please note his Comment #4.

My point has always remained the same.  Icons should not be moved around
  to address this issue -- doing so is a kludge.  CrystalSVG icons should
be in the "crystalsvg" directory; HiColor icons should be in the
"hicolor" directory; and (now) Oxygen icons should be in the "oxygen"
directory.  IIRC, Rex agreed with me when I originally stated this.

I think that it was wrong to rename the existing HiColor icons to
KDEClassic; it made no sense.  But, now with standardized icon names,
the installation of HiColor icons has become problematic due to the
possibility of more than one icon for a standard icon name being
installed.  The standard needs to address this as well as the above issue.

Note that this does mean that an application needs to supply ONE HiColor
icon for the DeskTop's menu entry.  The standard clearly states this.
If there isn't one, than a copy of one the is available is acceptable.
For many KDE applications, such an icon exists or did exist, but was
moved/removed.

Then any substitution should be done by the Iconloader code.  And, the
code should be configurable -- it should not be hard coded.  The reason
for this is simple: it is much easier to edit a small file in /etc/XDG/
than it is to change the code or to move the icons around.

> you might not like it given your need for order and consistency,

While a mix of icons is acceptable, the icon themes should not be more
mixed than is necessary.

> but a) most people care more for the branding aspect and

If this means that now even with the standard icon names that when using
  KDE and GNOME apps on the same desktop that they shouldn't be using the
same icons, then this is statement is simply wrong.  Branding is not
compatible with desktop standards and the integration of different 
desktops.  If you are saying that we should force people to use icons of 
the current KDE default theme when they have chosen a different theme, 
it makes no sense.

> b) there isn't enough manpower to provide additional "unthemed" icons
>  anyway.

We always say that, but if we took down the "Help NOT Wanted" sign, we
might be surprised at how much more manpower was available.

-- 
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]