qqc2-breeze-style

[Arjen Hiemstra]

On Monday, 12 April 2021 23:26:18 CEST Carl Schwan wrote:
> Le lundi, avril 12, 2021 10:20 PM, Nate Graham <nate at kde.org> a écrit :
> > [explicitly CCing Noah]
> > 
> 
> And I still have the same worries as before. Building a universal theming
> system will takes **years** to make in a way that won't feel like a big
> regression for our users.

It is going to take a while to develop yes. On the other hand, I do not really 
see another option. Maintaining four or more different styles also takes a lot 
of time and leads to us constantly having to reimplement stuff we already fixed 
in another place.

> 
> At least for the QML engine, some part like configuring the paddings,
> margins, borders will be relatively easy since those can be mapped to QQC2
> easily. That will be more complicated is everything that has to do with
> animations Just an example, implementing ripple effects, for example,
> require js in HTML, custom shaders in QML and custom c++ code for the
> animation in QtWidgets. Trying to abstract that will be hard but not
> impossible.

On the other hand, we barely do anything with animations in the current style. 
For starters, qqc2-desktop-style does not support animations so any animation 
from the QStyle is already missing, apart from a few that were manually added. 
Similary, Plasma's SVG themes do not have any animation as far as I know, so 
all animation in Plasma is currently custom and tied to the widget rather than 
the theme.

> 
> Another example of a hard part will be the scrollbars. Currently just
> looking at the different qstyle installed on my machine, I can see many
> completely behaviors and button placements. Again it's not impossible to
> solve by figuring out a good abstraction and adding tons of options. But at
> the end we will end up with a list of configuration options that are passed
> to the engine and two implementations that should be able to handle **all**
> the options required to implement the existing themes.
> 
> here for example to support an oxygen style scrollbar (written in scss)
> 
> scrollbar {
>  border-width: 0;
>  item {
>     color: ...
>  }
>  top-buttons {
>    move-top: {
>      display: true;
>      icon-name: ....
>      background: none;
> 
>    }
>    move-bottom: { display: false }
>  }
>  item-background {
>     box-shadow: inner 2px 2px grey;
>     border-radius: 2px
>     background-color: ...
>     &::hover {
>       background-color: ...
>     }
>  }
>  item {
>     margin: 2px
>     width: calc(100% - 4px);
>     background-color:
>     &::hover {
>       background-color: ...
>       box-shadow: outer 2px 2px blue;
>     }
>  }
>  bottom-buttons {
>    move-top: {
>      display: true;
>      icon-name: ....
>      background: none;
>    }
>    move-top: {
>      display: true;
>      icon-name: ....
>      background: none;
>    }
>  }
> }
> 
> This already seems like a lot of rules and I probably forgot many more...

It would already be a lot simpler if we had a `scrollbar-layout` or similar 
custom property to indicate what buttons to show where. Which is a requirement 
for the CSS parser anyway, we will need support for adding custom properties 
and similar stuff. On the other hand, what I like about CSS is that it is 
completely logic-less, which makes a bunch of things simpler.

> 
> A solution to reduce the number of rules to implement would be to allow
> the engine to accept textures provided by svg files. But that brings
> us back to the problem of it being too slow for the pinephone and require
> some hacks to pass some parameters to the theme (for example for the
> margins or the colors).

We will need some form of image support anyway. On the other hand, if we can 
avoid using images for everything, especially things that change dimensions, 
we can avoid a lot of the slowness of the current implementation.

> 
> Allowing to ship QQC2 themes with QStyles themes sounds a lot easier
> to implement compared to that. And sure it won't be perfect but the
> unified style also won't be perfect anytime soon.

Even if we dropped qqc2-desktop-style, that would still mean maintaining three 
different styles. And it doesn't solve any other problems, it means QStyles are 
still a pain to implement, qqc2 styles can break any application and Plasma 
and Applications cannot share style code.

> 
> Anyway, if someone wants to invest a lot of time in creating the unified
> theme, I won't stop them and I would happy to be proved wrong about my
> worries. But until then I will use the breeze qqc2 style on the desktop too
> because it's smoother and less buggy than the desktop style. I would even
> argue that we should ship it with our QML applications in Android.
> 
> Regards,
> Carl