On Wed, Sep 3, 2014 at 10:26 PM, Eike Hein <h...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel