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

Fri Dec 7 13:34:21 CET 2018

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 but one only should remove something when there's a replacement for it. Besides, you're talking about catching up. However, you do it already anyway because of Qt Widgets, don't you? What exactly is the issue then? It cannot be that difficult to integrate the perfectly working native styles you had in Qt Quick Controls 1 with Qt Quick Controls 2. You can see Jean-Michelle's earlier post where he's pointed to [an at least partially successful effort](https://github.com/KDE/qqc2-desktop-style) to achieve exactly what I'm talking about. I think it's within the resources of a small team to at the very least integrate that work if not porting your own from Qt Quick Controls 1.

On 7.12.18 13:35, Mitch Curtis wrote:

>> -----Original Message-----
>> From: Dimitar Dobrev
>> [<dpldobrev at protonmail.com>](mailto:dpldobrev at protonmail.com)
>> Sent: Friday, 7 December 2018 12:10 PM
>> To: Mitch Curtis
>> [<mitch.curtis at qt.io>](mailto:mitch.curtis at qt.io)
>> ; Jean-Michaël Celerier
>> [<jeanmichael.celerier at gmail.com>](mailto:jeanmichael.celerier at gmail.com)
>> Cc:
>> interest at qt-project.org
>> 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.
>
> From the blog post:
>
>> 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!
>
>> On 7.12.18 13:02, Mitch Curtis wrote:
>>
>>>> -----Original Message-----
>>>> From: Interest
>>>> [<interest-bounces at lists.qt-project.org>](mailto:interest-bounces at lists.qt-project.org)
>>>> On Behalf Of
>>>> Dimitar Dobrev via Interest
>>>> Sent: Friday, 7 December 2018 11:32 AM
>>>> To: Jean-Michaël Celerier
>>>> [<jeanmichael.celerier at gmail.com>](mailto:jeanmichael.celerier at gmail.com)
>>>> ;
>>>> interest at qt- 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.
>>
>>>> On 7.12.18 11:57, Jean-Michaël Celerier wrote:
>>>>
>>>>	(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
>>>> <
>>>> interest at lists.qt-project.org
>>>>
>>>> [<mailto:interest at lists.qt-project.org>](mailto:interest at lists.qt-project.org)
>>>>
>>>>>
>>>>
>>>> wrote:
>>>>
>>>>		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/>](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>](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
>>>> Interest at lists.qt-project.org
>>>>
>>>> [<mailto:Interest at lists.qt-
>>>> project.org>](mailto:Interest at lists.qt-project.org)
>>>>
>>>> https://lists.qt-project.org/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181207/fcec14df/attachment.html>