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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
