I wrote a sister post for my yesterdays one, hopefully this can clarify some terminology we throw around!
(previously: Breeze QtWidgets style changes to help us prepare for Union (Testers needed) )
4 Likes
I would debate that QtWidgets is “not very flexible”
The idea of “Union” using Plasma SVGs as somehow a better is dubious from a programmer’s point of view. The meaning of what the various items are in Plasma SVGs is often not obvious. Editing a corner radius, for example, in a Plasma SVG is a nightmare that will take hours (complexity depends on the radius wanted); making it dynamically adjustable even more work using XML parsing.
I think the current idea of generating the Qt Quick theme from the QStyle automatically is a good one. I think that making this better would be a better investment than what is currently proposed in Union. There are numerous tweaks in the QStyle to override widget events, for example, and I suspect Union will end up breaking the ability to tweak widget behaviour as needed.
For example, my QStyle adjusts scrollbar events. My scrollbar events adjustment currently automatically propagates from the QStyle to Qt Quick very well. I hope this is not going to be broken by Union. It also annoys me that the Plasma style doesn’t even use a standard QStyle scrollbar widget, and instead decides to draw its own inferior scrollbar. It would make more sense to use the more powerful QStyle in the Plasma style as well, rather than vice versa.
That is not the idea of Union, Union is based on CSS.
It is not a good solution, since it negates one advantage of QtQuick, which is GPU rendering.
It also does not work well for all components. For example menus are just re-implemented in qqc2-desktop-style and not based on the QStyle.
Apart from that, QStyles are not easy to distribute as compiled code, so they can’t be downloaded through the usual KNewStuff system.
Regarding your fear of missing features: Whatever is needed for styles can be added to Union. The set of supported features is not static or already decided.
Have you seen this recent Qt announcement on a potential future QCanvasPainter for imperative GPU rendering?
An analysis on each component on why QStyle<->QCCStyle cannot be generated by the other would also be interesting.
You could have the KNewStuff and CSS/SVG as an optional input to just create a dumbed-down QStyle for those who want that. Those who wish to have more low-level tweaks would not have to use it, and work could continue to improve the automation from QStyle in qqc2-desktop-style. I have a bad feeling that “Union” (given its ambitious sounding name) will end up doing more to destroy existing automation from the QStyle to QQC2.
I am also sceptical that “Union” devs would accept numerous complex low-level requests from theme developers, the complexity of required changes being even more than at present due to the extra abstraction layer.
Not mentioned prior aret also is Graphics View Framework | Qt Widgets | Qt 6.10.2 although, it is more specialized. It is only used by dolphin these days AFAICT.
It does not seem like a good layer to deal with that sort of issues.
Scroll speed is hardware/compositor level, everything else is software issues (lack of fractional scale/dpi, high dpi mouse support…) that can be fixed.
We support scrollbar speed adjustment settings in KWin after all.
And all that power hurts artists…
A Qt style isn’t meant as a hacking avenue, but as a visual style.
We have the toolkit, application layer and compositor layers to tweak behaviors.
I didn’t mention scrollbar speed. My scrollbars offer a unique UX that can’t realistically be implemented at any other level.
If that’s so unique that’s not in our community interest to focus any effort into maintaining it or even enabling it in any way shape of form.
1 Like
That’s a rather obnoxious statement to make, especially when you don’t have details on what I’m talking about (I’m busy right now but will raise this in detail later). It would be foolish to break superior UX for users, especially when it currently works very well.
Sorry this sounded harsh.
The xkcd pun was to let see a bit of a maintainer perspective when it comes to unique workflow and features.
In essence we can’t delve our dev resources into fringe use-cases.
And Union as any additional abstraction layer will have to rationalize what it allows, in order to get to our unifying UI goal.
You are free to fork our community work how much you want still.
I still am curious to hear about your use-case, maybe it has potential. You can’t have many users until you have shown it at least.