On Thursday, 2014-09-11, 15:53:57, Eike Hein wrote: > 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.
Why would hicolor be distro/ISV specific? > 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), I am afraid I can't follow. No distro would be involved in that, I am talking about a hicolor package that is provided alongside the spec. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
