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