Le mardi, avril 13, 2021 1:10 PM, Arjen Hiemstra <ahiems...@heimr.nl> a écrit :
> On Monday, 12 April 2021 23:26:18 CEST Carl Schwan wrote:
>
> > Le lundi, avril 12, 2021 10:20 PM, Nate Graham n...@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.
Yeah the lack of animations is a bit of a problem in the desktop and plasma
style.
The breeze qqc2 is a vast improvement in this aspect.
> > 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.
Yeah, custom css properties will be required and the parser will probably need
to be based on stylo (the rust css parser from firefox) since it's the only
one that is fast, available as a library, well tested and maintained.
>
> > 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.
It's probably worth investigating if we want to support custom geometries,
if we are fine with a rust dependency, it wouldn't be that hard to convert
svg path segment to both QPainter instructions and custom QGSGeometry with lyon.
That might in many cases be enough for not requiring to use images.
> > 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.
There is always tradeoff and it is hard to guess if it is easier to create and
maintain a completely new theme engine or maintain the already existing themes.
Short theme maintaining that we already have is easier, long term I can see a
point
about trying to unify everything.
> > 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
