On Thursday, 2014-09-11, 17:56:38, Eike Hein wrote: > On 11.09.2014 17:22, Kevin Krammer wrote: > > Hicolor is there for cases where the setup fails to provide any workspace > > or distribution specific theme. > > Yes. So I'm thinking ahead and telling you how that "setup" looks > like for a workspace: > > - Write a Qt platform plugin. Needs coding chops. We have them. What > about workspaces which don't? What about all the other toolkits be- > sides Qt? > > - Swap out icons in hicolor. > > Which do you think happens?
Depends on the wanted results. A platform plugin provide platform integration which icons are only a small part of. If the platform vendor wants Qt application to properly integrate with their choice of workspace, they will have a platform integration plugins. If they just want to have icons, they are very well able to ship their own version of hicolor fallback icons. This does not conflict with having a non-broken hicolor theme package to start with. > > 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? > > Because making Qt aware of an explicit theme involves writing a Qt > platform plugin. It means if you're a sys admin / distro you can no > longer solve your problem on the spec level (unless you swap out > icons in hicolor), you need to be aware Qt exists. Seems like a > layering violation to me. As I said above, it depends on the level of integration you'd like to achieve. There are lots of integration points provided by said plugin. > > 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. > > No, but it makes it a lot easier for distros to provide a complete > fallback (-> installing Oxygen or something else, setting it as > preferred fallback). It's less work than maintaining a complete hi- > color no one can agree on. I don't see why it would be difficult to agree on having a non-broken fallback. > > Or do you mean install the custom theme twice, once as itself and once as > > hicolor? > > Wait - I think I now understand why we're having trouble > communicating about this. > > You think a distro has the option to install Oxygen *as* > hicolor, right, making my preferred fallback thing seem > redundant? > > That's not so - because numerous apps install app icons > *into* the hicolor folder structure, including KDE apps, > and those can conflict with the icons in a theme. For > distro packagers that means they'd have to fix numerous > package installs to eliminate those conflicts. No, I mean providing their own hicolor theme if they want to (ab)use the fallback as their integration point. I really have to read the spec soon, but I have my doubt that it lists any app specific icons. Thus installing such into its paths should not conflict with anything already there. > So using any given theme *as* hicolor doesn't fly without > manual merging/maintenance work for packagers, which is > what I suggest to avoid with a 'preferred system fallback' > config knob. Assuming that a vendor wants to override the default hicolor package, then yes that will obviously require maintenance. This is no different with any other deviation from upstream. Again, having a shared setting, exposed via whatever mechanism (env variable, X11 property, file, ....) is orthogonal to having a working fallback. The fallback is hit when no other means of lookup, whether configurable or hardcoded, resulted in a matching icon. So it *must* at least contain all icons that are specified in the spec, it is an icon loader's last resort. 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
