Re: [kde-artists] Sorting the app icon mess

On Saturday 27 February 2010 01:00:22 am James Tyrer wrote:
> > Let's say we have an app called "foobar", foobar is built on KDE and
> > very popular. foobar installs its app icon (foobar.png, as defined in
> > foobar's desktop file) to /usr/share/icons/hicolor, the global
> > freedesktop.org icon theme (as per specification the ultimate
> > fallback to all implementations, be it on KDE, GNOME or XFCE). Oxygen
> > 
> >  (creators of KDE 4's default icon theme) feels that foobar needs
> > 
> > another icon to fit in with their icon theme, so they provide another
> > 
> >  foobar.png, obviously installed to /usr/share/icons/oxygen. The user
> >  however does not like Oxygen and uses Tango. Since foobar is so
> > 
> > popular, the Tango creators also decide to create a custom version of
> > 
> >  the icon that better fits in with their icon theme, this time
> > 
> > installed to /usr/share/icons/tango.
> 
> And now we have a problem which you have not anticipated.  The FooBar
> app can install an Oxygen icon and a Tango icon and those themes might
> also install those icons.  Two (possibly different) files in the same
> place is a problem.  What this means is that the HiColor (non) theme
> didn't solve the problem.

That is not really of any concern to us, we install one icon, that either 
needs to go to hicolor or oxygen, depend on whether the app maintainer wants 
to provide their own hicolor icon. Now, if they also decide to provide their 
own _different_ oxygen icon then they are conflicting with us, which either 
should be discussed to find a solution (e.g. exchanging icons, or changing our 
icon to fit what the maintainer likes about their custom one).
FTR, that is not even something the hicolor theme is supposed to solve anyway.

> > Here comes the inheritance as defined by the spec into the game.
> > 
> > First KDE will look for the icon in Tango (since that is the user
> > configured icon theme), then it will look in all themes that Tango
> > defines as inherint ones, then it will look in Oxygen, and if it
> > still cannot find the foobar icon, it will look in hicolor.
> > 
> > On a GNOME desktop it looks exactly the same, just that it wouldn't
> > check in Oxygen.
> 
> Actually, it should not check in Oxygen; it should check in the icon
> directory pointed to by the: "default.kde4" and should skip that if the
> link is not there.

Well, GNOME doesn't do either, and the spec does not imply that Oxygen or the 
default.kde4 theme must be searched at all.

> It should first be noted that it appears that you are talking only about
> apps which are shipped in the KDE modules since central maintenance of
> icons in separate apps is not possible.

Again. kdebase-runtime depends on oxygen-icons, every app depends on kdebase-
runtime, hence every app depends on oxygen-icons, so unless they want to 
maintain icons themselves, the icons are most likely maintained and stored 
within oxygen-icons, which makes central maintenance possible.

> The best solution to this problem is for the app to install a HiColor
> icon in the "hicolor" directory and an Oxygen icon in the "oxygen"
> directory.  If there is no HiColor icon, then the installer should make
> a link from the "hicolor" directory to the Oxygen icon.  This is what
> links are for.

How is that any different for just installing to hicolor?

> The solution to overwriting is not as simple.  The icon installer for
> the KDE app should not overwrite icons that are already there but the
> installer for the whole icon theme should.  Other solution require
> additional directories and can get complicated.

I am not exactly sure about what installer you are talking about, but not 
overwriting icons is probably a good idea, but that does not prevent app 
maintainers from manually overwriting (in that above presented case where they 
want to override a default oxygen icon they would probably be doing just that 
regardless of whether the "installer" allows it or not).

> Another part of the mess is that if apps install Oxygen and HiColor and
> the user has selected Tango that the icon shown will be Oxygen when
> running KDE-4.  This behavior should be configurable.  Actually, from a
> usability viewpoint, with separate apps, it would be better not to have
> Oxygen icons for them since the users are probably more familiar with
> the icons that come with the apps.  Configurability would fix that also.

Not of concern to the problem at hand IMHO.

regards,
Harald
______________________________________________________________________________
[email protected] |  https://mail.kde.org/mailman/listinfo/kde-artists