Plasma 5.22 Kickoff Notes

Arjen Hiemstra ahiemstra at heimr.nl
Wed Mar 10 17:38:34 GMT 2021


On Wednesday, 10 March 2021 13:57:31 CET Carl Schwan wrote:
> Le mercredi, mars 10, 2021 10:56 AM, Marco Martin <notmart at gmail.com> a 
écrit :
> > I knew from a long time it was to be the default style on plamo.. I
> > never really agreed to default to it on plasma mobile but since looked
> > like it was the majority decision i didn't oppose it too much (even
> > qqc2-desktop-style would be fine on plamo for now, there may have been
> > issues with using the plasma style )
> > A QQC2 style is not a plasma style, it's something that is very
> > difficult to maintain .. almost as much as a qstyle, really.
> > 
> > Now having this style in workspace puts all of us quite in a big
> > maintenance burden, throws away all the fixes done through the years
> > in qqc2-desktop-style, makes more difficult to identify where a bug
> > actually is and makes qml apps more inconsistent with qwidget ones.
> > Using it as default on the desktop would be a huge mistake as well,
> > would make hunting any bug much more difficult, putting a maintenance
> > burden and time sync that should be used instead to solve the issue of
> > how we really want to do themes, as this approach is really not
> > sustainable.
> > 
> > The real core issue is:
> > qqc2-desktop-styles are not suitable for generic 3rd party theming.
> > The name suggests otherwise, but that's simply not true.
> > they can control too much of the behavior of controls, to the point of
> > even adding new api if they desire so., and making applications to not
> > start at all if they contain any error (or even if the style uses a
> > qqc2 import version older than what the app uses)
> > so, every platform should really maintain one, as the effort to have a
> > correct one is huge already. (oh, and they can't be switched a runtime
> > without restarting the app)
> > 
> > For a 3rd party theming, is needed really something else way more
> > limited (and the fact that's more limited it's a feature)
> > something based upon some combination of css and images is really the
> > only proper way forward i can see.
> > And working towards a style that gives that, to me is a way better way
> > to spend hundreds of hours of development into.
> 
> I know that this topic has been discussed many times already but I don't
> think there is any perfect solutions for QQC2 theming of applications.
> 
> qqc2-desktop-style has the advantage of using in a few places the QStyle
> so some controls are looking native but in an usual Kirigami application
> many other components are looking the same as Breeze. You are for example
> still getting the new ToolArea from Plasma 5.21 even when using GTK2 QStyle.
> Since it is basically using the QPainter API, it is slower and use more
> memory than an optimized QQC2 theme would.
> 
> qqc2-plasma theme tries to make it easy to create themes by just using
> svg so that it should be possible to only use Inkscape to make one but
> unfortunately I think this fails because to make a plasma theme you need
> to understands many internal things to the theming engine. For example
> how to name every components, how the margin indicator works, what magic
> elements need to be added to change the behavior, ... There is also the
> problems of the themes not designed for Application UI but for Plasma so
> they looked horribly wrong on Plasma Mobile and using more memory than
> an optimized qqc2 theme.
> 
> qqc2-breeze-style has the problem of more maintenance cost and diverging
> from the normal breeze style, but at least it is efficient and looks
> good. So from an end user point of view for Plasma Mobile it is good. A
> problem I see is that for users to customize the look of the applications,
> more qqc2 will need to be developed and this isn't an easy task (but
> developing a QStyle or Plama theme isn't easy either).
> 
> A qqc2 css theme doesn't exist yet and I don't think this is a solution
> either. A css theme contains a set of rules and we would need to develop
> a qqc2 theme reading and supporting many rules. Currently the proof of
> concept use a ShadowedRectangle to support a few rules (shadow, border
> and colors),

The prototype uses ShadowedRectangle because I needed something quickly. The 
goal for the unified style was actually that each API variant is drawn using an 
optimal solution for that variant, so QPainter stuff for widgets but QtQuick 
Scene Graph stuff for QtQuick. 

> but if we want to make it viable to use, we wold need to
> be able to configure many more rules: customizing the width, color, style
> every border of a rectangle, the sizing of every elements, animations,
> transition, gradiant, background image, positioning, shadows, 

The question is actually if you should support all that. I personally think 
that CSS contains too much and we want to select a subset that we can properly 
support. 

> ... And those are non trivial thing to solve in both QML and QtWidgets world
> and more importantly making each control use this heavy weight QML
> components probably won't be cheap in term of performance. So we might end
> up with something too slow to be usable.

The proof of concept uses a total of one extra object compared to the most 
bare-bones implementation of the Button style that is possible and that extra 
object is there because of the extra indirection of going through 
ShadowedRectangle. As mentioned above, the idea here is that most of the work 
would be done through scene graph nodes, which are significantly lighter than 
having a whole bunch of QtQuick items.

The main problem with the unified style is the amount of work needed to get it 
from a proof of concept to something production ready. Ideally this should 
even be something that happens in upstream Qt but I do not see that happening. 
This means we will probably have to bite the bullet ourselves at some point, 
since I don't really see any other way forward long term.

- Arjen





More information about the Plasma-devel mailing list