[REVIEW REQUEST] Cleanup of unused or duplicated icons

[C. Boemann]

On Thursday 16 August 2012 19:20:35 Friedrich W. H. Kossebau wrote:
> 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/e
> ntry/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
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
Thanks a lot, this investigations is enough for me - let's get rid of the 
hicolor icons.