On Thursday, 2014-09-11, 17:05:43, Eike Hein wrote: > On 11.09.2014 16:09, Kevin Krammer wrote: > > Why would hicolor be distro/ISV specific? > > Because a hicolor theme everyone likes visually isn't going > to happen. People will want to modify what's in that fall- > back for theming reasons, and distros theme to differentiate > themselves.
Why would anyone want to change the fallback? The fallback is something you never ever want to see, it is a worst case scenario puffer. Like the safety net in a circus arena. I think what you mean is a default, like us using Oxygen/whatever, GNOME using Tango/whatever, etc. Hicolor is there for cases where the setup fails to provide any workspace or distribution specific theme. Its purpose (I have still not read the spec but that is the only thing that makes sense to me) is to make sure there is an icon if anything else has failed. A shared resource to avoid every application having to ship fallbacks for each used icon. > In the "hicolor as fallback" scheme, there are two ways to > affect what icons actually show in KF5 apps outside Plasma: > > - Make sure this environment outside Plasma, whatever it is, > has a Qt platform plugin available that reads some setting > somewhere that overrides hicolor by specifying a theme. Right, this is what a distributor or other workspace would do if they care about theming as a means of differentiation. > (This is how Plasma itself solves this.) Exactly. > - Manipulate what icons are actually in hicolor. Sure, if somebody wants to install their icon theme instead of hicolor, why not. But why not just have your theme as an explicit theme like everyone else and only get your theme in case the fallback path is triggered? Or do you mean install the custom theme twice, once as itself and once as hicolor? > If we introduce a "preferred system fallback theme" config > option in the spec that overrides hicolor, and make Qt aware > of it, that avoids either work, which is more extensible to > new environments. Sharing a setting that indicates a default theme name is of course a good goal, doesn't however fix the problem of the fallback being incomplete. I read that non Qt based systems use XSettings to exchange that information (on X11 only of course) so maybe we can have that in Qt as well? And come up with a way to do something equivalent on Wayland? 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
