There's no proper replacement for KIcon

[Harald Sitter]

On Wed, Sep 3, 2014 at 10:26 PM, Eike Hein <hein at kde.org> wrote:
> I think the fd.o spec pro-
> scribes the hicolor theme then?

^ this

>  In that case it would
> be up to the distro to make sure this works out.

That wouldn't help the original issue that we previously had a
hardcoded fallback to oxygen, in fact we still do as far as the
platform plugin is concerned [1]. So IIRC the effective lookup order
was user_theme (which in turn may have internal fallbacks defined) >
default_theme (oxygen) > hicolor. So even on windows you'd get oxygen
icons I suppose, without the user or the developer doing anything.

> I'm not sure what alternatives we have here. It's not
> reasonable for KF5 to override the platform plugin re-
> gardless of environment, and I don't think duplicating
> the platform plugin system inside KIcon or writing a
> wrapper around QIcon::fromTheme seems sensible.

To be honest I think this might be considered intentional
compatibility breakage because the original assumption that installing
something to oxygen and it will be available in the app regardless of
what the user configured seems wrong to me. The icon theme spec
outlines one solid fallback and that is hicolor.

*Assuming* as an application developer that KIcon/QIcon will also look
in oxygen in addition to hicolor seems an awful lot like writing
against the implementation rather than the API (the API in this case
being the spec I guess ;)).

So, IMO the correct solution to this is to install the icons one needs
to hicolor so that they are picked up unless provided by a user
configured theme, as outlined by the spec.

NB: I have no idea how this would or should work on windows or osx, so
this approach might be entirely pointless and non-functional there,
which in turn might actually be a reason to bring back something like
KIcon as to provide a grand unified way of getting 'the right' icon
looked up.

[1] https://bugs.kde.org/show_bug.cgi?id=336739

HS