[REVIEW REQUEST] Cleanup of unused or duplicated icons

[Friedrich W. H. Kossebau]

Am Donnerstag, 16. August 2012, 18:55:12 schrieb C. Boemann:
> On Thursday 16 August 2012 18:49:22 Friedrich W. H. Kossebau wrote:
> > Am Donnerstag, 16. August 2012, 18:37:13 schrieb C. Boemann:
> > > On Thursday 16 August 2012 16:38:55 Dag wrote:
> > > > Torsdag den 16. august 2012 16:19:29 Friedrich W. H. Kossebau skrev:
> > > > > I would say it is a misinformation, as Calligra depends on kdelibs
> > > > > (4.3),
> > > > > so indirectly depends on the Oxygen icon set (from 4.3). And there
> > > > > would be lots of "unknown" icons in the Calligra UI if Oxygen was
> > > > > not present, not only by what kdelibs uses.
> > > > > 
> > > > > I guess having icon copies was only needed with kolibs, right?
> > > > 
> > > > Eehh, don't really know the reason.
> > > 
> > > Well even though we install the oxygen icons because we depend on it,
> > > does not mean the user has the oxygen icon set selected. That other icon
> > > set will probably not have all needed icons, and that is why we need to
> > > provide the fallback icons aka hi color
> > 
> > AFAIK Oxygen icon set is the default fallback icon set with kdelibs. So if
> > a user selects another icon set, for any not found icons in there
> > KIconLoader will as last ressort pick the one from Oxygen.
> > That is why the Oxygen icon set is a hard dependency for kdelibs.
> > 
> > Otherwise Calligra would need to ship a complete set of all Oxygen icons
> > it
> > (and the used kdelibs parts) uses, as any icon might miss from the other
> > icon set.
> > 
> > So if there is kdelibs, there is also Oxygen icon set in the background.

> Oh that would be really nice if it is so. Can we find out somehow?

Hm, I cannot find it explicitely mentioned somewhere on a quick check.
Also not in buildsystem check, after all the Oxygen icon set is "just" a run-
time dependency. Still the distris have it as hard package dependency AFAIK 
(either kde-runtime or kdelibs) and it is part of any KDE SC, cmp. e.g. 
http://kde.org/info/4.9.0.php

The code at least seems to align with my "knowledge", cmp. 
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kdeui/icons/kiconloader.cpp#L603
--- 8< ---
void KIconLoaderPrivate::addBaseThemes(KIconThemeNode *node, const QString 
&appname)
{
    // Quote from the icon theme specification:
    //   The lookup is done first in the current theme, and then recursively
    //   in each of the current theme's parents, and finally in the
    //   default theme called "hicolor" (implementations may add more
    //   default themes before "hicolor", but "hicolor" must be last).
    //
    // So we first make sure that all inherited themes are added, then we
    // add the KDE default theme as fallback for all icons that might not be
    // present in an inherited theme, and hicolor goes last.

    addInheritedThemes(node, appname);
    addThemeByName(KIconTheme::defaultThemeName(), appname);
    addThemeByName("hicolor", appname);
}
--- 8< ---
where KIconTheme::defaultThemeName() is like:
--- 8< ---
QString KIconTheme::defaultThemeName()
{
    return QLatin1String("oxygen");
}
--- 8< ---


So seems it is more an informal hard dependency. But also a logic one: kdelibs 
uses the Oxygen icon set as much as it can, and as user of kdelibs we should 
be able to rely on that kdelibs does not ask for icons which are not existing.
And there is no Oxygen icon subset. And even more there is no "hicolor" icon 
theme with a declared minimum set of existing icons.

Perhaps #kde-devel can confirm this.

Cheers
Friedrich