On Wednesday, 21. May 2008, James Richard Tyrer wrote:
> Jakob Petsovits wrote:
> > On Wednesday, 21. May 2008, James Richard Tyrer wrote:
> >> Ah maybe.  However, we still need an icon named: "zoom" for fall back
> >> for missing zoom-* icons.  Are all KDE icon themes going to have all of
> >> the "zoom-*" icons.  I don't think so.
> >
> > No, that's the whole point that I tried to explain: no fallback could
> > reasonably cater for all the different zoom icons, so if a theme doesn't
> > have those then it better falls back to Oxygen
>
> Falling back to Oxygen is something that only KDE does.  You need to
> broaden your thinking to the free desktop with other applications, other
> toolkits, and other icon themes.  In short, you need to think outside
> the box -- KDE centric thinking is the box and it needs to go.

Other desktops and applications have fallback icons as well if they use this 
icon name. If for example Gimp wants to use page-zoom, they'd probably put 
their version into hicolor (as it's not included in the spec) which is used 
as fallback in case any 3rd party theme doesn't provide the icon.

So the procedure is exactly the same for other applications and toolkits, just 
that we're one of those, providing our version of the icon and the fallback 
method. We can expect other applications and toolkits to do the same.

The same use case that I used for my explanation applies just as well to 
GNOME/gnome-icon-theme/hicolor, Gtk+/hicolor, or whatever toolkit/fallback 
combination there is. I'm using Oxygen in order to sound less abstract than I 
already am, but I do very much consider other toolkits and 3rd party themes 
into the equation.

> > instead of using an incorrect icon.
> > Better inconsistent in the style than conveying a wrong metaphor.
>
> That is basically wrong.  Consistent style is more important.

More important than correctness? I beg to pardon.
If that is the case, why don't we just use a 3rd party theme's "unknown" icon 
for all icons that it doesn't provide?

Excuse me, but we have a major disagreement here.

> And, it is contrary to the theory of the new icon naming scheme.  The
> new icon names are supposed to form trees where they can fall back
> towards the root of the tree.

No, the idea is that they can fall back to any icon that still covers the same 
purpose than the original name, even if less specific. Nobody said that this 
needs to be the "root" icon, and moreover the actions category uses the 
icon "root" as namespace rather than base icon.

I say we shouldn't fall back where it doesn't make sense.

Regards,
  Jakob
______________________________________________________________________________
kde-artists@kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists