mart added a comment.
In D19392#421950 <https://phabricator.kde.org/D19392#421950>, @davidedmundson wrote: > > The problem with using -symbolic for all monochrome icons is that we'd have to create color icons without -symbolic to replace the old monochrome icons without -symbolic. > > Why would breeze need two versions? > > If an app requests -symbolic you get a black icon which we know we can colourise. > If the app doesn't request -symbolic you get an icon which happens to be all black. which screws up if it's a dark background > Also it's worth noting there's an FD.O icon spec rule (that will apply for all QIconEngines hopefully) if an app requests "foo-bar" and "foo-bar" doesn't exist, it will automatically load "foo" so if i requested foo-symbolic but foo was returned and is not monochrome, i will get a broken icon. > Us requesting "-symbolic" at an app level won't break anything. (though obviously we'll have to port a bunch of app code) tough is still a theme designer decision to put random monochrome icons in the non -symbolic section, that is a valid decision and i don't want to break it >> this tough is about doing something about it in KIconLoader which is completely ortogonal to this patch. > > That's absolutely not what this is about, because as you note putting it in KIconLoader wouldn't fix anything at all! > > We've got code in Plasma that colours icons. Then we put code in KIconLoader because we didn't account for widgets, now we're putting code here because eh, in kf6 i would love to drop plasmacore.iconitem, having just this item instead. > we didn't account for non-plasma - and we know this is a bodge that's going to get replaced as it doesn't work in a lot of cases. well, looking at how the gtk one works, i just vastly prefer our approach, exactly because it styles all icons and doesn't require to have -symbolic technically(and that maps a big part of the system color palette, while the gtk one doesn't). while the approach they taken is only applied to -symbolic, because it would destroy any normal icon, for the following reason: - the base class "fg" case which is most of the use case (what usually becomes black) is not indicated with a css class like "warning" or "success" is, but assumed for everything - in that case any color in the style: attribute of the tag is nuked, it seems with the !important css tag which isn'0t supported by either inkscape nor Qtsvg, so that the stylesheet can be applied (resulting in the screwup of any icon that wasn't explicitly done for it) while instead breeze needs a class set for everything and use fill:currentColor explicitly, so icons that don't want to use it are completely unaffected (the problem there is that is a bit inconvenient to do because inkscape is quite buggy in saving files using currentColor without breaking stuff) > If we are running Kirigami on gnome, you probably want to use a gnome icon set at which point this all breaks. I think the app would /need/ to request the "-symbolic" icon? > > I'm fully aware I'm being difficult, but I'm doing it because these half solutions keep going on forever and I'm trying to save us some time in the future. > If we do want changes in GTK4 and Qt6 we should be thinking about them now. so, for gtk4/qt6, the base qiconengine included in qt should support whatever coloring is used, in which case i wouldn't eed to do anything on my part.. tough that's for Qt6. It's important for me tough that in the final version, any icon can be styled, not only those that end with -symbolic REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D19392 To: mart, #kirigami Cc: ngraham, GB_2, ndavis, #vdg, cfeck, davidedmundson, plasma-devel, domson, dkardarakos, apol, mart, hein
