Plasma 5.22 Kickoff Notes

[Marco Martin]

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.

> 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

-- 
Marco Martin