Plasma 5.22 Kickoff Notes

[Carl Schwan]

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), 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, ... 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.

Carl Schwan

>
> The fact that things like that are needed to keep the VDG kids
> excited, is not an argument, we really cannot compromise the
> quality for the sake of that.
>
> On Wed, Mar 10, 2021 at 10:21 AM David Redondo kde at david-redondo.de wrote:
>
> > Thank you for your opinion Marco.
> > Am Mittwoch, 10. März 2021, 09:30:35 CET schrieb Marco Martin:
> >
> > > wasn't present at the kickoff meeting so commenting just here, just now.
> > > I'm quite against qqc2-breeze-style and i think it was a mistake.
> > > It was that the style used in plasma-mobile had bugs, so let's just
> > > write a whole new style from scratch putting more maintainance burden
> > > on the time being.
> >
> > I also was worried about the maintenance burden in the meeting being double
> > and having to keep everything in sync.
> > Furthermore a controls style does not only change the visuals but can also
> > influence the behavior of the controls. I feel that the goal of qqc2-breeze-
> > style to be as similar as possible in that regard to the styles shipped with
> > Qt is not one we should aim for. It means that it will lead to a (more) split
> > desktop experience, missing fixes in qqc2-desktop-style where the default
> > behavior is different to widgets or just bad.
> > As written in the notes many of were suprised of the inclusion, including me.
> > I thought it would maybe go to extragear, but the issue I think was that the
> > review mail never specified the intended place for the project.
> > Regards,
> > David
>
> --
>
> Marco Martin

</notmart at gmail.com>