Plasma 5.22 Kickoff Notes

[Arjen Hiemstra]

On Wednesday, 10 March 2021 14:24:02 CET Marco Martin wrote:
> On Wed, Mar 10, 2021 at 1:57 PM Carl Schwan <carl at carlschwan.eu> wrote:
> > 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.
> 
> do we have actual reliable numbers or is just a feeling?
> On the memory side one
> can say that on the other hand the desktop style even if keeps big textures
> in memory, it creates many less qobjects, so is to be seen how much one
> thing counteracts the other.
> On the painting speed, i can already say there will be exactly one
> scenario where
> the desktop style is measurably much slower: animated resizes of widgets.
> everything else not really. when the texture is uploaded, is uploaded,
> don't have to redo it for every frame.

We do, to a certain extent. I did a fairly extensive benchmark as part of the 
unified style PoC, see https://invent.kde.org/ahiemstra/qtunifiedstyle/-/tree/
master/benchmark . One of the conclusions from that was that the desktop style 
is pretty good with regards to creation times, but the Plasma style really is 
quite bad there. On the other hand, as you say, the desktop style is quite 
slow when it needs to do constant repaints like when resizing an item.

> 
> > 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
> 
> a basic proof of concept exists as qtunified style done by Arjen.
> It's of course a proof of concept and would need a lot more
> development to be viable,
> but that's where we should start imo.
> 
> > concept use a ShadowedRectangle to support a few rules (shadow, border
> > and colors), 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, gradient, background image, positioning, shadows, ... 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 idea is to have c++ elements which paint with shaders, like
> ShadowedRectangle in Kirigami,
> but with other features which are still missing, such as gradients,
> inset shadows and what not.
> those would be performant. then of course you need to put a limit on
> what is customizable and what isn't,
> but that is true for every approach.
> Except perhaps in cases of qqc2 style or qstyle from the ground up,
> and that is *exactly* what makes both of them not acceptable.
> A good solution *has* to define boundaries from which the theme
> developer can't technically go out of

Yeah I agree actually, one of the things I actually liked with regards to CSS 
is that it is very strongly declarative, so it is actually fairly abstract. A 
CSS file says very little about how something needs to be rendered, it simply 
states what should be rendered. This means that the implementation that uses 
that CSS file is quite free to determine the how, as long as it looks correct. 
This also already sets some boundaries on what is possible, as there is 
basically no logic in a CSS file. That said, I would say supporting everything 
in CSS would be too much and we should select a reasonable subset of things to 
support.

- Arjen