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

On Thursday, 25 de February de 2010 13:22:38 Harald Sitter wrote:
> Salut!
> 
> I'd like to get the app icon mess sorted once and for all.
> 
> In case you do not know what I mean by "app icon mess" I'll first try to
> explain the situation, as precise as possible.
> Quite some time ago freedesktop.org published a specification for icon
> themes and how they get implemented in the individual desktop environments
> or UI libraries. [1]
> 
> Along the lines of this spec there is following to be found:
> > In order to have a place for third party applications to install their
> > icons there should always exist a theme called "hicolor" [1]. The data
> > for the hicolor theme is availible for download at:
> > http://www.freedesktop.org/standards/icon-theme-spec.html.
> > Implementations are required to look in the "hicolor" theme if an icon
> > was not found in the current theme.
> 
> As simple as this may sound, it implies one very important fact: apps
> should install their icons to the hicolor theme. But why is this?
> 
> 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.
> 
> 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.
> 
> The reason KDE is also looking in Oxygen and GNOME is not, is due to the
> 
> following part of the spec:
> > (implementations may add more default themes before "hicolor", but
> > "hicolor" must be last)
> 
> So, KDE's implementation adds oxygen as additional fallback, while GNOME
> does not.
> 
> This means two things:
> a) anything stored in oxygen will be found in KDE, despite the icon set
> configured by the user
> b) if an app does not install a fallback icon to hicolor and the GNOME icon
> theme does not provide one, the app will have no icon in GNOME, XFCE...!!!
> 
> Here you can see the mess.
> 
> Currently bovo, from kdegames is such a case. bovo does not install an app
> icon to hicolor but assumes the user is using KDE and thus gets the icon
> from Oxygen. Quite frankly said, this is no problem for any icon that is
> shown within the app, because those icons get loaded via KDE and thus
> above mentioned additional lookup in Oxygen applies. BUT in the menu
> implementations it will have no icon, because those are not looking in
> Oxygen but only the configured default + its fallbacks + hicolor. Which
> means bovo does not have an icon in the GNOME menu.
> 
> So that is why every app should install its icon to hicolor (or at least
> some hicolorified version of the icon, that can be used by other
> desktops). For a lot of KDE applications that is currently not the case
> because they rely on oxygen for that.
> 
> This is quite a problem in terms of cross desktop user experience, but
> cannot be solved easily. Since oxygen app icons are usually the default
> icons of KDE apps, they should technically install those to hicolor. BUT
> they do not maintain the icons themselves, but oxygen does, and oxygen
> prefers to keep them all in one place (for maintainability and everything,
> which is very sensible).
> 
> This leads to 3 cases:
> 1) $appmaintainer copied the icon from oyxgen to their source and installs
> it to hicolor (for example the case for yakuake)
> 2) $appmaintainer moved the icon from oxygen to their source and installs
> it to hicolor
> 3) $appmaintainer does not know or care, and their app does not have an
> icon in the menus of GNOME and XFCE
> 
> problems:
> 1) duplication (this means that the icon is installed twice), unmaintained
> (the oxygen team does only maintain the icons in the oxygen source, and
> thus the maintainer must ensure that the icons stay in sync)
> 2) no duplication but even more unmaintained as with 1), since there is not
> even the chance of syncing since the icon is out of the oxygen team's scope
> 3) no cross desktop user experience
> 
> Obviously we need some sensible solution to all this, which is not exactly
> trivial. We could either keep on doing 1) or 2) and possibly have outdated
> and ugly etc. icons on desktops other than KDE, or we find a way that
> ensures central maintenance from the oxygen team without too much hassle
> for them.
> 
> Since only the latter is an option here is what I would imagine to be a
> working approach to solving the problem:
> Split out specific application icons into a separate part of oxygen
> (oxygen- icons-apps or something) and install those icons not to the
> oxygen theme, but the hicolor theme.
> This would not even increase dependencies, since this part could still be
> deployed within the regular oxygen-icons source, and since kdebase-runtime
> depends on oxygen-icons anyway, and every KDE gui app depends on kdebase-
> runtime this consequently leads to the fact that every KDE gui app depends
> on oxygen-icons anyway, which means that shipping the icons as part of
> oxygen- icons is just as good as shipping them along the source of those
> applications, as long as they get installed to hicolor.
> 
> This could for example look like this in SVN:
> trunk/kdesupport/oxygen-icons/...
> trunk/kdesupport/oxygen-icons/app-icons/...
> trunk/kdesupport/oxygen-icons/app-icons/32x32/yakuake.png
> 
> Everything that is not in app-icons gets installed to
> $PREFIX/share/icons/oxygen, and the stuff in app-icons to
> $PREFIX/share/icons/hicolor.
> 
> Using this approach we have central maintenance and at the same time
> provide hicolor icons for all applications.
> 
> Opinions about this?
> 
> [1] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-
> latest.html
> 
> regards,
> Harald
I really don't have an opinion on the subject other than .... i want to keep 
everything I maintain in one centralized place as far as icon goes, think of 
if as a big basket of icons you can use as you see fit. 
-- 
Oxygen coordinator  
______________________________________________________________________________
[email protected] |  https://mail.kde.org/mailman/listinfo/kde-artists