There's no proper replacement for KIcon

[Eike Hein]

On 11.09.2014 15:43, Kevin Krammer wrote:
> Having a configurable fallback before the final fallback can't hurt, but that
> doesn't solve the actual problem of hicolor being incomplete.
> It is just a work around.

Sort of, except I think the outcome is more or less the
same - either a distro/ISV decides on a particular set of
icons to roll into hicolor to make things look good
(which means work) or they get an explicit config knob to
do that merging.

I don't think you really get out of distributed work in
either scenario - in the "fix hicolor" scenario you have
many distros replicating the work (because no, deciding
on a single hicolor isn't going to happen, if only because
theming is one of the things distros do to differentiate
themselves), in the "fix the spec" scenario you need to
fix many implementations of the spec. The advantage of
the latter is that it happens once and is done; new
distros (and new icons) will be made for a long time to
come.

Another trick that came up would be to enhance the lookup
algo in the spec to allow one level of inheritance for
hicolor ...


Cheers,
Eike