venerdì 30 novembre 2018

And now for something completely different: QtQuick.Controls 2 for the desktop!

As you might know, the QtQuick.Controls 1 module has been officially deprecated since Qt 5.11; this had been in the air already since quite some time, given that the development of the module had almost stopped. It looks like The Qt Company is mostly investing on the more performing QtQuick.Controls 2 module, and is inviting developers to switch over to that — at least for new projects.

However, there currently isn't a style available that would make an application using the QtQuick.Controls 2 look native on the desktop. There has been an attempt at it, but it soon turned into a custom style for the KDE desktop environment. So, some time ago I decided to give it a try: I started by forking the project of the KDE guys and as a first step I removed the dependency on the KDE libraries.

A button generated by the QML QQC2 desktop style
A traditional QPushButton
The difference (enhanced in Gimp, or you wouldn't see a thing)

It's a work in progress, and it probably has a long way to go before it's usable for a real world product, but I'm trying my best to turn it into something you can trust: this is a project where Test Driven Development fits very well, because in order to ensure pixel by pixel visual compatibility (that's my goal indeed!) I'm running a test where I create the same widget using the QtWidgets module and with this QQC2 style, and comparing the resulting surfaces for equality. In the pictures above you can see how the Button element looked earlier today (before I fixed it 🙂), compared to a traditional QPushButton: the test code creates a visual diff of the two images, and the test passes only if the resulting image is pitch black (with a very small tolerance for possible differences in font antialiasing).

For the time being I'm focusing my attention on the visual appearance of the individual widgets and their implicit size, but I'll soon add tests (and code) for layouts and interaction behaviours. I also need to extend the tests: they are currently run in GitLab CI for Linux only (where I can test the Fusion and the Windows styles), but I hope to find a way to run them in AppVeyor and on Mac OS. By the way, if someone knows of a CI service which would allow me to run my graphical tests on a Mac, please let me know in the comments.

This is an early notice that the project exists; if you have some time and energy to spare, you are very welcome to help me with the development.

Etichette: , , , ,

9 Commenti:

Blogger Notmart ha detto...

> There has been an attempt at it, but it soon turned into a custom style for the KDE desktop environment.

It has *one* dependency, all the rest is optional

3 dicembre 2018 21:22  
Blogger Alberto Mardegan ha detto...

Yes, but it uses constants and behaviours from Kirigami, while I'm looking for a platform native look & feel.

3 dicembre 2018 21:27  
Blogger Dave ha detto...


> Yes, but it uses constants and behaviours from Kirigami, while I'm looking for a platform native look & feel.

No, there are some constants and palette that come via kirigami framework but that in turn loads the desktop plugin for the source of those values, which brings us the platform native look & feel.

That abstraction partly exists as you often want those core values (like the palette etc) outside of the stock components.

At some point you'll need a form layout to get a native look and feel, at which point you'll have a second import - and you'll have created basically same situation that you've just forked away from.

3 dicembre 2018 23:46  
Blogger Alberto Mardegan ha detto...

> No, there are some constants and palette that come via kirigami framework but that in turn loads the desktop plugin for the source of those values, which brings us the platform native look & feel.

It doesn't look to be the case. For spacing and padding, the Kirigami.Units class is being used, and that defines its own measurements.

Though to be fully honest, at the time when I decided to fork the project I didn't look into this: I simply saw that the import had been renamed to "org.kde.desktop" so I assumed that it was a KDE-specific style. If that's not the case, and if the goal is indeed to have a 1:1 mapping with the QtWidgets's look & feel, then I'll be glad to walk back and contribute to the original project -- but at the moment I've a different feeling.

> At some point you'll need a form layout to get a native look and feel, at which point you'll have a second import - and you'll have created basically same situation that you've just forked away from.

I haven't looked into layouts yet, but my initial idea was to provide a singleton class that would define the default margins, and the developers would have to explicitly specify these margins when using the standard QtQuick.Layouts. If there was a way to achieve a QtWidget-like layout without the developer's cooperation (that is, the developer would just use the QtQuick.Layouts module without setting any spacing or margins), than that would be the best, indeed.

4 dicembre 2018 00:03  
Blogger Dave ha detto...

>and if the goal is indeed to have a 1:1 mapping with the QtWidgets's look & feel

It's definitely a goal. If something looks different it's a bug - I like the idea of your tests. I'm not going to remotely pretend everything current is flawless here, but I don't think there's anything that can't be fixed in the current system.

The name org.kde.desktop was just to avoid an import namespace clash should Qt ever release a version.

Units is a bit of an odd-ball in general, but if you look through the logs we're moving away from it for the most part.

---

I don't mind if you fork, it's open source.
The problem is we then split future contributors and that sucks for us both.

If there's specific things that we need to fix because it means we can't match the look, I'm willing to help look into it, I'm sure Marco would too.

---

Form layouts are more complex than margins. We left align text fields, OS X right aligns, Windows does something else. I'm not sure Kirigami actually does that yet, but it's got an API defined such that one could.

4 dicembre 2018 00:36  
Anonymous Anonimo ha detto...

Pixel by pixel visual compatibility should also includes animations (i.e. smooth transitions on hover), and QStyle themes implement animations via polishing widgets: https://github.com/KDE/breeze/blob/master/kstyle/breezestyle.cpp#L216

Will this be addressed somehow?

4 dicembre 2018 01:31  
Anonymous Sune ha detto...

I kind of find it sad that you have changed one of the licensing options - basically making it impossible to move your enhancements back to kde's style

4 dicembre 2018 07:48  
Blogger Notmart ha detto...

> It doesn't look to be the case. For spacing and padding, the Kirigami.Units class is being used, and that defines its own measurements.

We have ah HIG, and following a style is important.
Kirigami is themeable (same mechanism QQC2 is using, actually) in which any of those, Theme, Units or any control can be redefined, that's how we have a very different behavior on some things on Android for instance.
This can be used to take values and behaviors from any platform, whatever "platform" means in a given context.
so, any of this is upstreamable without the need of forking the whole project

4 dicembre 2018 13:19  
Blogger Notmart ha detto...

> Pixel by pixel visual compatibility should also includes animations (i.e. smooth transitions on hover), and QStyle themes implement animations via polishing widgets: https://github.com/KDE/breeze/blob/master/kstyle/breezestyle.cpp#L216

if the style implements its own animations with its own times, or anything that does bypassing the standard Qt apis (for instance some styles have custom colors for some things which don't come from qpalette but save them in their own config files)
then, there is absolutely nothing that can be done, all of it is an unaccessible black box to the QML part.
Also, trying to implement animations by qstyle repaints would be extremely inefficient as qstyle (being very old and outdated technology) only does software painting, which then needs a complete texture upload on the gpu for each frame, which for something in such an hoth path as the style for every application, is unacceptable.

4 dicembre 2018 13:27  

Posta un commento

Iscriviti a Commenti sul post [Atom]

<< Home page