[Interest] Qt Quick Controls 1 deprecated but no native styles for Qt Quick Controls 2?

[Jean-Michaël Celerier]

(Reposting as per the wishes of OP, sorry for the *déjà-vu*)

I've used this for desktop style (before they tied it to other KDE libs -
looking at you, ExtraCmakeModules) :
https://github.com/KDE/qqc2-desktop-style

It works fine for me (though you have to mingle a bit with the font
settings to get the exact same text rendering than on QWidget in my
experience)

-------
Jean-Michaël Celerier
http://www.jcelerier.name


On Fri, Dec 7, 2018 at 10:21 AM Dimitar Dobrev via Interest <

Please disregard my previous e-mail, actually, delete it if possible. I
mean "Qt Quick Controls 1" rather than "Qt Quick 1".
This e-mail is a better version of the comments I've left
<https://blog.qt.io/blog/2018/12/06/qt-5-12-lts-released/>.
The release notes for Qt 5.12 <https://wiki.qt.io/New_Features_in_Qt_5.12>
worry me quite a little. They say that Qt Quick Controls 1 is deprecated.
There's a single but key reason this is extremely bad news. And this reason
is the lack of native styles in Qt Quick Controls 2. This alone renders Qt
Quick Controls 2 useless for building decent desktop applications. This in
turn means our only option remains Qt Widgets - a piece of technology which
is like a horse carriage. Good for its time but useless in the era of
automobiles. The very notion of suggesting that for desktop development in
2018 we would be deprived of a simple declarative language for GUI, a
flexible scripting language to match, GPU-based optimizations and all other
wonderful features Qt Quick has to offer - is ridiculous at best. If it's
true that Qt Quick Controls 1 is deprecated and Qt Quick Controls 2 won't
get native styles any time soon, this simply means Qt has severely
regressed in its offerings to developers.
In addition, I have tracked Qt Quick from its very beginning in 2010 and I
clearly remember you, the Qt developers, advertised Qt Quick as the new
generation of tools and technologies for building graphical user
interfaces. You said Qt Widgets was not (yet) deprecated but fully finished
and would receive few new features and basic optimizations. I hope you will
spare me effort of quotations in support of that above because I think such
actions would be rather ugly. You know what I'm talking about. I see this
as an additional problem to the one described in my first paragraph. You
have made a promise and repeated that promise for years. If Qt Quick
Controls 1 is no more and so are native styles, there's unfortunately one
conclusion - that you have reneged on this promise.
I am asking of the entire community of developers and management of Qt -
please prove me wrong. Please assure me I'm overreacting. Please tell me Qt
Quick Controls 2 is going to get native styles so that we have the
outstanding Qt Quick Controls 2 for the desktop again.
Best regards,
Dimitar Dobrev
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest

[Mitch Curtis]

-----Original Message-----
Dobrev via Interest
Sent: Friday, 7 December 2018 11:32 AM
project.org
Subject: Re: [Interest] Qt Quick Controls 1 deprecated but no native styles
for Qt Quick Controls 2?
Thank you for your suggestion, Jean-Michaël, it might be - or might've been -
useful. But I'm afraid your very suggestion contains the problems which
would arise if we don't get official support. A little dependence on KDE, a
little tweaking of fonts - 20 more a littles and all hell breaks loose. So this is
not an issue any 3rd party can properly solve, we need native styles in Qt
Quick Controls 2 itself.

There have been efforts around this (i.e research, proof of concepts):

https://blog.qt.io/blog/2017/02/06/native-look-feel/

There are a bunch of us interested in pursuing it further. One of the big problems is finding time for it amongst all of the other things we have to do.

(Reposting as per the wishes of OP, sorry for the déjà-vu)
I've used this for desktop style (before they tied it to other KDE libs -
looking at you, ExtraCmakeModules) : https://github.com/KDE/qqc2-
desktop-style
It works fine for me (though you have to mingle a bit with the font
settings to get the exact same text rendering than on QWidget in my
experience)
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Fri, Dec 7, 2018 at 10:21 AM Dimitar Dobrev via Interest
Please disregard my previous e-mail, actually, delete it if
possible. I mean "Qt Quick Controls 1" rather than "Qt Quick 1".
This e-mail is a better version of the comments I've left
<https://blog.qt.io/blog/2018/12/06/qt-5-12-lts-released/> .
The release notes for Qt 5.12
<https://wiki.qt.io/New_Features_in_Qt_5.12> worry me quite a little. They
say that Qt Quick Controls 1 is deprecated. There's a single but key reason
this is extremely bad news. And this reason is the lack of native styles in Qt
Quick Controls 2. This alone renders Qt Quick Controls 2 useless for building
decent desktop applications. This in turn means our only option remains Qt
Widgets - a piece of technology which is like a horse carriage. Good for its
time but useless in the era of automobiles. The very notion of suggesting
that for desktop development in 2018 we would be deprived of a simple
declarative language for GUI, a flexible scripting language to match, GPU-
based optimizations and all other wonderful features Qt Quick has to offer -
is ridiculous at best. If it's true that Qt Quick Controls 1 is deprecated and Qt
Quick Controls 2 won't get native styles any time soon, this simply means Qt
has severely regressed in its offerings to developers.
In addition, I have tracked Qt Quick from its very beginning in
2010 and I clearly remember you, the Qt developers, advertised Qt Quick as
the new generation of tools and technologies for building graphical user
interfaces. You said Qt Widgets was not (yet) deprecated but fully finished
and would receive few new features and basic optimizations. I hope you will
spare me effort of quotations in support of that above because I think such
actions would be rather ugly. You know what I'm talking about. I see this as
an additional problem to the one described in my first paragraph. You have
made a promise and repeated that promise for years. If Qt Quick Controls 1 is
no more and so are native styles, there's unfortunately one conclusion - that
you have reneged on this promise.
I am asking of the entire community of developers and
management of Qt - please prove me wrong. Please assure me I'm
overreacting. Please tell me Qt Quick Controls 2 is going to get native styles
so that we have the outstanding Qt Quick Controls 2 for the desktop again.
Best regards,
Dimitar Dobrev
_______________________________________________
Interest mailing list
project.org>
https://lists.qt-project.org/listinfo/interest

[Mitch Curtis]

-----Original Message-----
Sent: Friday, 7 December 2018 12:10 PM
Subject: Re: [Interest] Qt Quick Controls 1 deprecated but no native styles
for Qt Quick Controls 2?
I have seen this post and I'm afraid even this incomplete effort is far from
what I'm talking about. It's a deviation from the very essence of Qt which is
cross-platform development. Even if you go for using native controls
underneath, it needs to be hidden from developers unlike what this blog
post explains. What I'm talking about is something you actually used to have
working, with Qt Quick Controls 1. Now, I've read and understood that Qt
Quick Controls 2 are very different underneath for performance reasons but
the bottomline is - this doesn't matter. As Qt developers we want natively
looking and acting components which neither this blog post nor Qt Quick
Controls 2 provide at present.
Since December last year, the controls team has been researching a bit small scale on a new project to offer controls with true native look-and-feel. The aim is to do the alternative to the above standing, and explore how feasible it would be to wrap actual native controls into a cross platform Qt API. Such ideas is nothing new of course, and have been discussed many times, at least internally. One of the problems is that different platforms can vary quite much API-wise, especially for more complex controls like tab-, and split views, with some having a rich API, while others are more limited. And unifying that into a common useable Qt API is a challenge.
Currently we have prototyped a set of controls, together with a plugin-based framework and a few backends for testing (uikit, appkit, android). The API is small and strict so that it can be realized on all supported (and future) platforms. As such, the controls become rather black box, since we cannot make assumptions on how they are implemented by the backends. Still, there will be times when you need to detail how your application should work on a specific platform. For that reason we plan to open up, and factor out, the various backends into separate libraries that can be accessed directly. Those libraries will wrap parts of the native APIs more closely, and offer building blocks specific to the platform, or controls with a broader set of functions and properties. They will be more open than the common controls, giving access to the native controls they wrap, to let you dig into to native development whenever you need to fill gaps that falls outside our own scope. In the end, it should be easy and straightforward to mix cross-platform controls, platform-specific controls, and native code in your application.

I wasn't involved in the work done so far, but as I understand it, this approach is a necessity in order to have anything _close_ to being maintainable by the small team that we have. If I remember correctly, the other option is to generate 1:1 wrappers of the native APIs in QML, which will likely have its own problems, and, in the context of your cross-platform comment, is further from Qt's cross-platform nature.

It's also a good way to get all of the current and future native fanciness that we wouldn't get with e.g. a QStyle-based approach. We want (or at least I want) to free ourselves of the burden of playing catch-up with native styles.

However... you said that this doesn't matter, and that it's all wrong and incomplete (I think you missed the "prototyped" part there) and terrible. So, I would be very interested in hearing your proposed solution for native Qt Quick Controls 2 styles. Keep in mind it has to be maintainable by a very small team. We're not Apple or Google. Oh and every OS has different sets of controls with different animations, behaviour and appearance.

Anddd..... GO!

Post by Mitch Curtis

-----Original Message-----
Dimitar Dobrev via Interest
Sent: Friday, 7 December 2018 11:32 AM
Subject: Re: [Interest] Qt Quick Controls 1 deprecated but no native
styles for Qt Quick Controls 2?
Thank you for your suggestion, Jean-Michaël, it might be - or
might've been - useful. But I'm afraid your very suggestion contains
the problems which would arise if we don't get official support. A
little dependence on KDE, a little tweaking of fonts - 20 more a
littles and all hell breaks loose. So this is not an issue any 3rd
party can properly solve, we need native styles in Qt Quick Controls 2

itself.

Post by Mitch Curtis
https://blog.qt.io/blog/2017/02/06/native-look-feel/
There are a bunch of us interested in pursuing it further. One of the big

problems is finding time for it amongst all of the other things we have to do.

Post by Mitch Curtis

(Reposting as per the wishes of OP, sorry for the déjà-vu)
I've used this for desktop style (before they tied it to other KDE
https://github.com/KDE/qqc2- desktop-style
It works fine for me (though you have to mingle a bit with the font
settings to get the exact same text rendering than on QWidget in my
experience)
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Fri, Dec 7, 2018 at 10:21 AM Dimitar Dobrev via Interest
Please disregard my previous e-mail, actually, delete it if
possible. I mean "Qt Quick Controls 1" rather than "Qt Quick 1".
This e-mail is a better version of the comments I've left
<https://blog.qt.io/blog/2018/12/06/qt-5-12-lts-released/> .
The release notes for Qt 5.12
<https://wiki.qt.io/New_Features_in_Qt_5.12> worry me quite a
little. They say that Qt Quick Controls 1 is deprecated. There's a
single but key reason this is extremely bad news. And this reason is
the lack of native styles in Qt Quick Controls 2. This alone renders
Qt Quick Controls 2 useless for building decent desktop applications.
This in turn means our only option remains Qt Widgets - a piece of
technology which is like a horse carriage. Good for its time but
useless in the era of automobiles. The very notion of suggesting that
for desktop development in 2018 we would be deprived of a simple
declarative language for GUI, a flexible scripting language to match,
GPU- based optimizations and all other wonderful features Qt Quick
has to offer - is ridiculous at best. If it's true that Qt Quick
Controls 1 is deprecated and Qt Quick Controls 2 won't get native styles

any time soon, this simply means Qt has severely regressed in its offerings to
developers.

Post by Mitch Curtis

In addition, I have tracked Qt Quick from its very beginning in
2010 and I clearly remember you, the Qt developers, advertised Qt
Quick as the new generation of tools and technologies for building
graphical user interfaces. You said Qt Widgets was not (yet)
deprecated but fully finished and would receive few new features and
basic optimizations. I hope you will spare me effort of quotations in
support of that above because I think such actions would be rather
ugly. You know what I'm talking about. I see this as an additional
problem to the one described in my first paragraph. You have made a
promise and repeated that promise for years. If Qt Quick Controls 1
is no more and so are native styles, there's unfortunately one conclusion -

that you have reneged on this promise.

Post by Mitch Curtis

I am asking of the entire community of developers and

management of

Post by Mitch Curtis

Qt - please prove me wrong. Please assure me I'm overreacting. Please
tell me Qt Quick Controls 2 is going to get native styles so that we
have the outstanding Qt Quick Controls 2 for the desktop again.
Best regards,
Dimitar Dobrev
_______________________________________________
Interest mailing list
project.org>
https://lists.qt-project.org/listinfo/interest

[d3fault]

Post by Mitch Curtis
Keep in mind it has to be maintainable by a very
small team.

I'm shocked to learn that Qt's flagship module (GUI) is only
maintained by a very small team. Bad utilization of resources.

d3fault

[Mitch Curtis]

Accidentally sent this privately.

-----Original Message-----
From: Mitch Curtis
Sent: Friday, 7 December 2018 2:12 PM
Subject: RE: [Interest] Qt Quick Controls 1 deprecated but no native styles for
Qt Quick Controls 2?

Well, if you have nothing better than what you used to, stick with
that. This is my proposal. That is, I do understand what problems you
see in QStyle

Are you sure? :D Personally, I have so far avoided having to touch QStyle
code, working mainly on Qt Quick, but let's take what Giuseppe was referring

Giuseppe D'Angelo via Interest
[snip]
2) At the very core of native styling in Qt there's QStyle, which uses
CPU-based rendering, relying on pixel perfect output provided by
QPainter. (Take a look into a style class, you'll found thousands of
QPainter draw calls). A native style built for QQC2 will mean one of

http://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/styles/qwindowsstyle.
cpp - 2401 lines
http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/styles/windowsvista/q
windowsxpstyle.cpp - 4243 lines
http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/styles/windowsvista/q
windowsvistastyle.cpp - 2405 lines
This, for me, is why I would never want to base future desktop styling on
QStyle. I don't think this is maintainable or future-proof at all. That's just my
opinion though. I don't speak for anyone else.

but one only should remove something when there's a replacement for it.

They haven't been removed though?

[Dimitar Dobrev]

About touching QStyle code, I simply don't see it happen without
justifying the super-massive investment required. In other words, IMHO,
there isn't enough demand for native QQC2 styles to justify it.

If this lack of demand is a fact, my personal guess for the reason
behind it is that too much time has passed by now and most people have
made their peace with the fact that Qt Widgets is the only viable option
for cross-platform GUI-s. But given which year we are, "is" doesn't
necessarily mean "should". So hereby I make my personal demand for
native styles in Qt Quick Controls 2. My hope is that enough programmers
follow so that we generate enough of it as you said.

[Nyall Dawson]

Post by Dimitar Dobrev
If this lack of demand is a fact, my personal guess for the reason
behind it is that too much time has passed by now and most people have
made their peace with the fact that Qt Widgets is the only viable option
for cross-platform GUI-s.

That's very much the case here.

I'd also be be extremely reluctant to spend any significant time in
porting away from Qt Widgets until the future direction of QQC2/the
future of QWidgets is clearer.

Nyall

[Andrew Ialacci]

Please someone correct me if I am wrong:

iOS user guidelines do not state “You must use our Buttons, ListViews, Switches and make your apps look like ours.”

They instead outline things like how small a button should be for touch interaction, and how a user expects to navigate an application of a particular type. Most of the UI specific requirements are straightforward to satisfy and there for good reason.

Not to be rude, but try actually reading the iOS HIG:
https://developer.apple.com/design/human-interface-guidelines/ios<https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/>

It’s really not that bad.

Not sure what type of application you’re working on, but the standards for UI design IN GENERAL have gone above and beyond just throwing prebuilt controls (from any framework) together. Apple expects the app to look nice and function well, regardless of what the underlying tech is. I can’t think of any 3rd party application that I use regularly which doesn’t have it’s own unique look and feel to it.

I would be more concerned about having an application rejected for functional reasons than UI related


Obviously It would be wonderful if Qt had released QQC2 fully complete with every style for every platform and every usage scenario ready to go. For XYZ reason, they weren’t able to. Instead we have a solid base which includes a template system that you can customize to suit your needs.





From: Interest <interest-***@lists.qt-project.org> on behalf of Sylvain Pointeau <***@gmail.com>
Date: Monday, December 10, 2018 at 1:31 PM
To: "***@qt.io" <***@qt.io>
Cc: Qt Project <***@qt-project.org>
Subject: Re: [Interest] Qt Quick Controls 1 deprecated but no native styles for Qt Quick Controls 2?


On Mon, Dec 10, 2018 at 9:19 AM Tuukka Turunen <***@qt.io<mailto:***@qt.io>> wrote:

Hi,

If Qt Widgets meet your needs, no need to port away from them. Widgets continue to be fully supported and actively maintained.

If you need to create cross-platform app with a dynamic UI, custom style, perhaps also running on touch based devices, different screen sizes etc, Qt Quick Controls 2 is a better fit.

If you are mostly happy with Qt Widgets, but miss some additional features, please tell about your needs. Make suggestions using bugreports.qt.io<http://bugreports.qt.io> or vote for existing suggestions.

Yours,

Tuukka


And what would you recommend for an app being in the app store or mac store?
if the app is not following the strict guidelines I guess it will be rejected?
are we then doomed with QtWidgets, never been able to use the fabulous qt quick?

[Nelson, Michael]

No peace made here. Our app relies on QQC1 heavily for supporting 4 different OS platforms. I am not at all happy with their deprecation, nor with a lack of any well supported QML-based alternative on the horizon.

Mike

-----Original Message-----
From: Interest <interest-***@lists.qt-project.org> On Behalf Of ***@free.fr
Sent: Sunday, December 9, 2018 10:25 AM
To: ***@qt-project.org
Subject: Re: [Interest] Qt Quick Controls 1 deprecated but no native styles for Qt Quick Controls 2?

Post by Dimitar Dobrev

there isn't enough demand for native QQC2 styles to justify it.

If this lack of demand is a fact, my personal guess for the reason
behind it is that too much time has passed by now and most people have
made their peace with the fact that Qt Widgets is the only viable
option for cross-platform GUI-s.

Definitely the case here. We reverted to Widgets and dropped any attempt to use QQC until they are both reasonably fast (not QQC1) and about feature complete (not QQC2 at the moment).

Quentin.
_______________________________________________
Interest mailing list
***@lists.qt-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_interest&d=DwIGaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=81ZrscQ2yIyG6ANaI07JBq6GmZkaYdjZEl0tfKL-7tQ&m=o0hYzBMJuesch799SphcNbXeZk6V-Kb6GzE8Nvd2RaI&s=Ir2evTrlzXgWpL1M5GvkdvGDqlPxrXMfpkLc4ffVYBQ&e=
Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

[Sylvain Pointeau]

What about the app store and mac store, we can never know if this will be
accepted if the ui does not follow the standard.

[Benjamin TERRIER]

Post by Nelson, Michael
Definitely the case here. We reverted to Widgets and dropped any
attempt to use QQC until they are both reasonably fast (not QQC1) and
about feature complete (not QQC2 at the moment).

Qt Quick Controls 1 were not feature complete for a desktop use.

They do look nice and all because they use QStyle, but the offer a
very poor user experience.
I did use them at some point to develop a desktop application and
faced many pitfalls.

If you want an example, take a look at QTBUG-47658
(https://bugreports.qt.io/browse/QTBUG-47658).
In short, focus is not handled properly and trying to use keyboard
shortcuts can result in user inputting text in another element.
I believe this is way worse that not having a native look and feel.

These kinds of errors was enough for me to go away from Qt Quick
Controls 1 and will not suggest to anyone to use them for any reason.
So now it is either Widgets or Controls 2 depending if I want a native
look and feel or animated UI.

BR,

Benjamin

[Jean-Michaël Celerier]

Might be the case but then who said the software emulation in question

cannot be based on QPainter? We have QQuickPaintedItem, for instance.

I'd like to see it before I believe it - for instance I know that at least
on my software, using a QOpenGLViewport-backed QGraphicsView is quite
slower and more laggy than a CPU-rendered one, consistently, on macOS,
windows and linux (and I have a fairly good GPU).

Qt Quick Controls have no animations by default

but QQC 1 is deprecated.
And QQC 2 has animations by default - I invite you to go to QtCreator and
press File / New project / Qt application / Qt Quick Application - Swipe
and interact with it.

just because of a small number of corner cases.

these really aren't that small in my experience. Also, no tree view -> no
go for a *lot* of technical apps.

In my experience QPainter is quite faster than LLVMPipe or other
openGL software rendering solutions.

Might be the case but then who said the software emulation in question
cannot be based on QPainter? We have QQuickPaintedItem, for instance.

Also, Qt Widgets does not have as many fancy animations / tweening
everywhere by default that would make stuff slower.

Qt Quick Controls have no animations by default except possibly native
ones (in 1).

If we look at the other UI toolkits, WPF which is also
scene-graph-backed has a lot of cases where it fallbacks to software

Exactly - we don't need to get stuck with a framework as old as Widgets
just because of a small number of corner cases.