Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Nelson, Michael via Interest]

A fair question perhaps for OSS community but many on this list pay for 
licensing and support precisely because we don't have time to fix everything 
ourselves.

MIke


Confidential - Company Proprietary

-Original Message-
From: Interest  On Behalf Of Volker Hilsheimer
Sent: Thursday, February 24, 2022 10:39 AM
To: Qt Interest 
Subject: Re: [Interest] Is there a good alternative to the QML Controls in Qt6 
for native desktop integration purposes?

> On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
>>> On Mo, 2022-02-21 at 16:42 +0100, Mark Gaiser wrote:
>>> Hi,
>>>
>>> I'm facing so many bugs in QML Controls in Qt6 (they used to be
>>> Controls V2 in the Qt 5.x
>>> days) that I don't want to use them at all anymore. They are bugged
>>> beyond repair and downright unusable for native desktop integration 
>>> purposes.
>>>
>>> Is there another good open source component set out there that
>>> integrates with the desktop. Specifically with Windows but preferably also 
>>> with Linux (kde and gnome) and Mac.
>>>
>>> Using QWidgets should not be an alternative as it slows down
>>> development a lot. But given the crap that QML Controls is makes me 
>>> consider switching to QWidgets instead.
>>
>> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner 
>>  wrote:
>> Hi,
>>
>> QML is nice for basic applications but widgets is important for
>> professional, technical and high-density applications.
>>
>> But that doesn't matter. From my point of view Qt stopped being
>> developed as a desktop framework a long time ago. Other industries seems to 
>> have priority now.
>
> Well, it was nearly good enough in the Qt5 days with Controls V1.
> All they needed was a better set of controls to accommodate mobile more and 
> reduce complexity in V1.
>
> What they did - conceptually - with V2 was good.
> But it seems like they just left it in alpha quality and call it "ok" to 
> replace V1.. That was a mistake.
> It needed much more development time to be a proper replacement.
>
> We're now like ~8 years past the introduction of the V2 set...
> And it still has really severe bugs that just interrupt usability. 8 years...
> So I doubt it will be getting any better at all.
>


Hi All,

Thanks for keeping it civilised.

Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
originally designed for mobile and embedded platforms, and indeed, that shows 
when using them for the desktop.

I’m happy that at least in The Qt Company we are now in a position that allows 
us to put more focus on the desktop, and that we are are able to do more than 
maintenance and catching up with what’s happening on the underlying platforms. 
That includes the journey of making Qt Quick Controls a great toolkit for the 
desktop as well. In Qt 6 so far we have had first implementations of the native 
styles - yes, those require more work; we have made a number of improvements to 
item views, including a TreeView now in Qt 6.3; a first set of standard dialogs 
is in Qt 6.2 and more are coming in 6.3. We have worked on some architectural 
issues that are problematic on the desktop, such as keyboard navigation and 
focus handling, and there is a fair amount of more work needed there as well.

I’m not going to claim that all things will be wonderful any moment now; 
there’s plenty of work that needs to be done. But things do get better, both 
with Qt Quick Controls, and with Qt Widgets as well.

What keeps confusing me personally is how few people in the community seem to 
find it interesting to contribute to either of our UI frameworks in Qt. If I 
take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 12 
years old, has 47 votes”. I sat down on Tuesday evening to check what it would 
take to implement hiding of rows in a QFormLayout; after a few hours I had a 
working implementation, which is right now on its way into the dev branch. The 
hardest part, as it so often is, was writing a unit test.

Now, I understand that not everybody finds it fun to do that kind of thing on a 
Tuesday evening. But given the apparently high interest in this feature, that 
nobody seems to have tried to give it a shot in 12 years is really puzzling me. 
When Nokia acquired Trolltech, it didn’t take a crystal ball to see that the 
focus won’t be the desktop. And one answer to this was to move Qt under Open 
Governance so that anyone could contribute to Qt and make sure that it stays 
awesome also for domains that Nokia won’t care much about.

Evidently, the people commenting in this thread care deeply enough about Qt on 
the desktop to participate in the discussion. And I suppose most of us on this 
list are software engineers, many perhaps for more reasons than to put food on 
the table. My question to you is: how can we make it easier, or more fun, or 
more motivating to contribute to Qt, and to help with making things better?


Volker


___
Interest mailing list
Interest@qt-project.org

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[Nelson, Michael]

+1 for idea that mobile support has not been the priority in QtCo's mind that I 
need it to be.
+1 for idea that filing bug reports and voting for them did not result in my 
concerns being addressed. UX with QML across mobile and desktop platforms could 
be better but many issues simply sit unaddressed.

Still, cross-platform support is nevertheless strong and QML is indeed a great 
language for UI, so I'm still a paying customer, for now. Keeping an eye on 
Flutter, though. 

Best regards,


MICHAEL NELSON | Sr. Software Engineer
T  703-406-2800, 341
michael.nel...@otthydromet.com | www.otthydromet.com



-Original Message-
From: Interest  On Behalf Of Jason H
Sent: Monday, March 22, 2021 10:23 AM
To: Roland Hughes 
Cc: interest 
Subject: Re: [Interest] The willy-nilly deletion of convenience, methods (was: 
Mixing Commercial and Open...)

>
> Even Jason's company, you remember Jason right? QML's biggest, and
> possibly __only__, fan. Even his company dumped Qt. The medical device
> clients I've worked for have also dumped Qt.
>
> It isn't the FUD that is obsolete, just the management of Qt.

I'm apparently Qt's biggest fan boy? Yes, I still think Qt (and yes, QML) is 
rockstar technology. My problems aren't with the API. It's that QtCorp has 
chipped away at the LGPL license from Nokia. And the stuff I wanted Qt to do, 
it didn't, even when under a commercial license.

Qt completely delivered is promise in us getting something to market, but when 
it was finally feature complete,  that something had more native code in it 
than Qt, because we were using using Qt just for the UI. Taking that and 
writing a UI abstraction to native was not that hard.

Qt *could have* made that port away so much harder, but because it's mobile 
support was so lacking, it was actually quite easy once we put our heads in it.

I'm also at a new company and I've suggested Qt up for evaluation, to replace 
the patchwork of libraries they are currently using.  We will see how the talks 
go... I doubt we will be using Qt6, regardless. Roland, what did those 
companies move to?

The problems I want fixed aren't technical. It's with the project's direction 
and management. "Open Governance" has not manifest the way I thought it would. 
Filling bugs and voting for them got my issues neglected. The constant 
relicensing to, of what was LGPL, to be under GPL 3. But these are issues that 
can be fixed with the stroke of a pen, or banging on a keyboard for a bit.

Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as a 
supported platform? A debian package would go along way to introduce people to 
Qt there in the hobbyist sector, but it's a compile-it-for-yourself situation. 
Qt continues to get beat by HTML5, but it shouldn't. Especially giving the 
WebGL plugin. But there just isn't that effort to enable that segment. There is 
no grass roots support for Qt as a result. And with the licensing issues of 
late, they've ensured that there won't be. This means that they have to rely on 
and cater to the big spenders boys in the market.
___
Interest mailing list
Interest@qt-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_interest=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=8eAioAP_sVFxZBs09SfrVELmNNKGDfcu3_znNi5BQuE=EJGZhrEuvpS6kt2IyI31RZNxODe8TUxAk6KWuVInpiY=
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.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The Mobile Agenda?

[Nelson, Michael]

Jason, thanks for making these great points focused on missing features. Let's 
also not forget mobile specific bugs that sit unaddressed.

Mike

-Original Message-
From: Interest  On Behalf Of Jason H
Sent: Saturday, January 4, 2020 3:49 PM
To: Lars Knoll ; interestqt-project.org 

Subject: [Interest] The Mobile Agenda?

So it looks like the QtWS 2019 videos are up on YouTube.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DYmwAeS-5FojPA=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=udWwVeDC5d8x9i-GGrsUlyzaDh_8l_874S9CaY6DA3g=kVDYbsUThHDxyV5SM35vedYZIUsyXduaRGqMScK30PM=
  "Qt 6 will bring massive improvements to QML and 3D development"

At time 53:40 Lars is asked a question about mobile, and answers "We will 
continue to support them. Was that the answer you were looking for? (giggles)" 
- Actually, no it is not.
At 57:00 Lars takes another question about mobile, and responds with a hesitant 
"Um, yes..." and continues" We have a lot of ideas... want to make sure Qt is 
working nicely on mobile.. things have been moving quickly... have to catch up 
there".
Actually the QA segment ended up being bookended by Mobile questions.

Well I'm glad to hear Lars admit that there is catching up to do, but I take 
issue with the claim that things have been moving quickly. The majority of 
mobile features that I and others are requesting are not bleeding edge, it is 
basic things, like
* NFC on iOS (Available iOS 11, September 19, 2017, 2+y)
* Media keys (volume, play/pause, etc., Since before Qt 5.2)
* Push Notifications (Since before Qt 5.2)
* Display control (Since before Qt 5.2)
* Battery Info (Since before Qt 5.2)
* Vibration/haptics control (Since before Qt 5.2)
* DeviceInfo (model, OS version, hardware enumeration, etc)
* Biometric authentication
* Datatype conversion (Java and ObjC to Qt types and back)

Many of these are not that hard, the code is known and settled, I've posted 
code where I think it helps, but the issue is for every app I make, I have the 
friction of adding 8 of my own classes to every project... which is composed of 
bout 8 files, and the tome doctoring manifests and plists). The expense of 
these classes is over, but these classes that took me days to create and test 
in environments where I am not expert. I hack at native Objective C and 
Android, and those experiences are troubling. I don't mind for some really 
weird feature, but what is being asked for by me and the community is pretty 
basic stuff. Objective-C code examples are becoming rarer as Swift takes over.  
The experience of using Eclipse or XCode is another problem itself, as the Qt 
integration is less than ideal. (Even ignoring having to use 2 IDEs to code.)

Mobile (in general) really hasn't advanced in any way that Qt needs to react 
to, there's a lot of new biometrics stuff, but really we only need a way to 
integrate for authentication. (Fingerprint, FaceID, etc) Also the only thing I 
know Android has changed lately is the permission requests, but Qt already has 
a helper for that.

A lot of these needs are tracked at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugreports.qt.io_browse_QTBUG-2D74049=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=udWwVeDC5d8x9i-GGrsUlyzaDh_8l_874S9CaY6DA3g=Z8qkrPvJrbw_WWF92VSjRB54ItmnT7UUxrEeriWJKXY=
  which was opened 11 months ago, but there has not been *any* activity, at 
least visibly.

However I have had several mobile support issues serviced and closed, but I 
also have a commercial support agreement.

If you are interested in my current code (that I recently refactored to be more 
granular than a monolithic catch-all shim that I had before) I can see about 
getting it shared to Qt, at least as inspiration (I don't use D-ptrs and am not 
subject to binary compatibility constraints). I think the most complicated bit 
on anyone's list is the Push Notifications, as the two platforms have different 
message structures.

So my question to Lars is:
Lars, can we get a better (in terms of: better stated, more attention, schedule 
clarity) commitment to mobile in 2020? I think with not a lot of effort we 
could get everything of what we are asking for, and then we can get out of your 
hair.




___
Interest mailing list
Interest@qt-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_interest=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=udWwVeDC5d8x9i-GGrsUlyzaDh_8l_874S9CaY6DA3g=FTPeFfzPXBpqCgbrFfZh3XPZEBSfpXptennpQBOjwjQ=
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 

Re: [Interest] import sitecustomize fails 5.12.4, OSX

[Nelson, Michael]

I'm still at xcode 10.3. I'm hoping you're able to report your update to Qt 
5.12.5 made it all work again.

Mike

-Original Message-
From: Interest  On Behalf Of Jason H
Sent: Tuesday, October 8, 2019 12:38 PM
To: Jason H 
Cc: interestqt-project.org 
Subject: Re: [Interest] import sitecustomize fails 5.12.4, OSX

This part is still true:
> I'm stuck in XCode hell. I upgraded XCode because I needed to work with a 
> iPhone 11 (iOS 13), which required me to install XCode 11, which created 
> issues.  I started a new project and got:
> 11:27:26: Starting: "/usr/bin/make" clean -j4 'import sitecustomize'
> failed; use -v for traceback Traceback (most recent call last):
>   File "/Users/jhihn/Qt/5.12.4/ios/mkspecs/features/uikit/devices.py", line 
> 78, in 
> if is_suitable_runtime(runtimes, runtime_name, args.platform, 
> args.minimum_deployment_target):
>   File "/Users/jhihn/Qt/5.12.4/ios/mkspecs/features/uikit/devices.py", line 
> 53, in is_suitable_runtime
> and "unavailable" not in runtime["availability"] \
> KeyError: 'availability'
>
> Not sure if 5.12.5 or 5.13 will fix?


But this part is not an issue, was due to a bad include path, ignore this 
part!!:
> Curiously, my old legacy app is still working though.  But compilation does 
> not stop and it gets through many of my own files until finally bombing out 
> at:

 > In file included from 
 > /Users/jhihn/Projects/ios_mobile_app/ios/platformshim_ios.mm:1:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIScreen.h:12:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UITraitCollection.h:13:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIInterface.h:11:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIColor.h:13:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/CoreImage.framework/Headers/CoreImage.h:15:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/CoreImage.framework/Headers/CIImage.h:10:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CoreVideo.h:29:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVPixelBuffer.h:462:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVPixelBufferIOSurface.h:26:
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
> /Developer/SDKs/iPhoneOS13.0.sdk/System/Library/Frameworks/IOSurface.f
> ramework/Headers/IOSurfaceRef.h:15:96: error: expected ';' after top
> level declarator

___
Interest mailing list
Interest@qt-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_interest=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=YIT7NYrY5xWg4RNEaF9tpPLfokAX3I88ou7rjhgIcYE=8DU3PkQ5gRLBKJHsnTMUD1OL84OWsvY7rbxgGGwHuLo=
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.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] No 5.12.5 for OSX?

[Nelson, Michael]

Yes, completed an update to 5.12.5 on mac running macOS 10.14.6 with no 
troubles.

Mike


-Original Message-
From: Interest  On Behalf Of Jason H
Sent: Thursday, October 10, 2019 2:48 PM
To: interestqt-project.org 
Subject: [Interest] No 5.12.5 for OSX?

Has any Mac user updated via the Maintenance tool to use 5.12.5?

I'm getting "No update available."
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.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt Quick Controls 1/2 and Surface Pro stylus pen

[Nelson, Michael]

Using Qt 5.12.4 standard build, I find stylus pen fails to operate any Qt Quick 
Controls 1 or 2, meaning, I can't operate any button, scroll, checkbox, or 
combo-box on a Microsoft Surface Pro tablet using the stylus pen. Is there a 
way to make this work?

Thanks,
Mike
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.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] How to manage build.gradle content?

[Nelson, Michael]

I wanted to prompt user to enable location services if needed, so I followed 
the example 
here.

To successfully build, I needed to add the following to my build.gradle file:
implementation 'com.google.android.gms:play-services-location:16.0.0'

However, the build.gradle file is in the build directory, created on qmake, and 
I don't always keep this build directory around. So, how do I ensure the 
build.gradle file has the required line following every qmake? Or, am I 
approaching this problem of dependencies incorrectly?

Thanks,
Mike


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.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Build problems, Android app on Qt 5.12.2

[Nelson, Michael]

Questions:
1) What successful tool sets are working for others to build Qt apps for 
Android?
2) Any idea what might be causing the following problem?

Using these tools:
   Qt 5.12.2
   Android SDK 28
   Android SDK Tools 26.1.1
   Android NDK r19c
   Java jdk1.8.0_172

androiddeployqt fails:

:compileDebugAidl FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileDebugAidl'.
> java.io.IOException: com.android.ide.common.process.ProcessException: Error 
> while executing process 
> C:\Users\nelson\AppData\Local\Android\Sdk\build-tools\29.0.0-rc1\aidl.exe 
> with arguments ...

Thanks,
Mike

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.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Nelson, Michael]

+1

Thank you Jason for being so vocal and expressing the concerns of other 
invested users so well.

Mike

-Original Message-
From: Interest  On Behalf Of Jason H
Sent: Wednesday, February 27, 2019 1:35 PM
To: Tuukka Turunen 
Cc: interestqt-project. org 
Subject: Re: [Interest] Fwd: vs. Flutter

Ok, thanks for clarifying that.

It's not just me though, there are *many* people using Qt that have +1d me and 
stated that they agree with me. Your customer survey reported 20% using Mobile. 
I'm just very vocal about it. I've done many Mobile apps in Qt, each with their 
own constellation of features that Qt does not cover. However as someone with 
extensive linux experience, learning Android is it's own thing. Activities and 
BroadcastReceivers, all in Java. The best way to manage that is with JNI, which 
is it's own beast... Once you get that working, then comes the iOS version, 
which is completely separate concepts and technologies.

Again, we're not looking to every possible API to be supported, just the common 
ones that we all use, that are an essential part of the mobile experience. The 
80/20 proposition.

My expectation is as follows: That a developer new to Qt, can create an app in 
QML on one platform and then have it "just work" by adding the other iOS or 
Android kit. This is mostly realized as long as you're just talking about 
putting things on the screen. But as soon as you want to do things like Push 
Notifications (or even Local Notifications) you're into a world of pain. The 
thing is, there is a huge amount of overlap. We just want the overlapping parts 
covered. It's not an unreasonable ask for a cross platform UI.

You say you're "investing in and improving" Mobile. I just don't see it. I've 
been actively using Qt on mobile since 5.4. I've gone over the release notes 
from each release and they are minor. iOS got some accessibility stuff, Android 
got Services. There have been efforts to keep things working, but nothing 
really new has been added.

5.2
- iOS/Android platforms added
In terms of big picture:
5.3
-iOS platform plugin:
-- Support for input methods added.
-- Support for word completion and spell checking added.
-- Support for QClipboard added.
-- "Hide keyboard" gesture added.
- WinRt/8
- Android: Bluetooth
- Positioning: added iOS Android.
5.4
- iOS
-- Accessibility support added. This enables Qt applications to be read by 
VoiceOver.
-- iOS port now uses fat builds with both 32-bit and 64-bit support.
-- Improved support for iPhone6/6+.
-- QtQuick Controls now uses native text selection and popup menus.
-- Default theme fonts now uses Dynamic Type, which is based on user system 
settings.
5.5 - Nothing*
5.6
- NFC
-- Android
5.7
- Android
-- Android Services
5.8 - Nothing*
5.9 - Nothing*
5.10 - Nothing*
5.11 - Nothing*
5.12 - Nothing*

*Nothing does not mean nothing at all. The iOS and android modules are clearly 
being maintained, and in a lot of cases iOS and Android platforms is being 
added to existing features. (Like adding android support to Qt3D(5.5), 
Bluetooth LE (5.5), NFC(5.6), etc.)

We're very happy that Qt is supporting these platforms, but the fear is that 
unless Qt also adds modules for Mobile APIs and delivers what developers expect 
to already exist on the platform, people will choose other toolkits like 
Flutter, ReactNative, Xamarian, and that undermines the mobile investment. I 
*want* Qt to be a top-tier cross-platform solution on mobile. It does some 
things excellently - better than anywhere else. I like not having to learn 
AVFoundation to record or playback audio and video, and then have to learn the 
Android way. Qt has delivered on this exceedingly well. I just want the same 
for the other things that Mobile Developers (and Users) expect. Some things are 
so easy in Qt. But to make a full-fledged Mobile app, Qt falls short and you're 
in a painful world of platform-sepecifics very quickly, which limits the 
adoption of Qt.

Unless Qt commits to Mobile APIs, I'm just going to switch to Flutter for any 
new apps, and only maintain the Qt ones. I'd rather bite that bullet once 
rather than having to maintain separate code bases for each platform. Thanks to 
this discussion, I've gone from biggest champion of Qt to, well, not an 
advocate on Mobile. I had always held onto hope that these things would get 
done "eventually", but I see now that's not the intent. Maybe this is done to 
protect V-Play, but not having any Qt mobile users won't help them either.

Your every response has indicated this will not happen, just that mobile will 
follow the other platforms. I don't understand why Qt won't commit to adding 
the missing Mobile APIs.


> Sent: Wednesday, February 27, 2019 at 12:03 PM
> From: "Tuukka Turunen" 
> To: "Jason H" 
> Cc: "Bernhard B" , "interestqt-project. org" 
> 
> Subject: Re: [Interest] Fwd: vs. Flutter
>
>
> Hi,
>
> No, that is not correct understanding. Mobile is well maintained and 
> developed further - just like the