[Interest] Fwd: vs. Flutter
Nelson, Michael
mnelson at sutron.com
Wed Feb 27 21:23:00 CET 2019
+1
Thank you Jason for being so vocal and expressing the concerns of other invested users so well.
Mike
-----Original Message-----
From: Interest <interest-bounces at qt-project.org> On Behalf Of Jason H
Sent: Wednesday, February 27, 2019 1:35 PM
To: Tuukka Turunen <tuukka.turunen at qt.io>
Cc: interestqt-project. org <interest at qt-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" <tuukka.turunen at qt.io>
> To: "Jason H" <jhihn at gmx.com>
> Cc: "Bernhard B" <schluchti at gmail.com>, "interestqt-project. org" <interest at qt-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 desktop and embedded platforms.
>
> We are constantly investing to the mobile and improving it with each release. For all the new features we always aim to get it running cross-platform, including mobile, whenever possible. So the functionality of mobile grows constantly, just like desktop and embedded.
>
> I do understand that you would like to have more of the device related items (volume control, brightness, ...) captured to a Qt API. But lack of this should not be seen as equal to lack of investment to mobile. What I wrote about it being relative easy to implement could be seen positively as well - at least I did not mean it in any way negative or insulting.
>
> Yours,
>
> Tuukka
>
> On 27/02/2019, 10.19, "Jason H" <jhihn at gmx.com> wrote:
>
> So am I correct interpreting that Qt on mobile is "finished", and we're on our own? (Aside from maintenance) Your statement "often quite straightforward to capture in a cross-platform API." seems like a "let them eat cake" moment. I really think you are missing the point that these "straightforward" are anything but. Who knows Objective C and Java? Not many. Not to mention there are enough pain points in moving to another platform already. I believe the promise of cross platform Qt is at least to handle the code.
>
> What would it take to get Qt to commit to supporting device APIs?
>
> > Sent: Tuesday, February 26, 2019 at 11:34 PM
> > From: "Tuukka Turunen" <tuukka.turunen at qt.io>
> > To: "Jason H" <jhihn at gmx.com>
> > Cc: "Bernhard B" <schluchti at gmail.com>, "interestqt-project. org" <interest at qt-project.org>
> > Subject: Re: [Interest] Fwd: vs. Flutter
> >
> >
> > Hi,
> >
> > Like you said, different users have slightly different needs, but there are also many things common. Our focus recently has been to make sure that old and new Qt features work nicely on mobile and in making sure new mobile platforms are supported swiftly. A lot of effort was put to WinRT / UWP to be supported in addition to iOS and Android. It is true that we have not been actively extending the support for device APIs, even though these are often quite straightforward to capture in a cross-platform API.
> >
> > Yours,
> >
> > Tuukka
> >
> > From: Jason H <jhihn at gmx.com>
> > Date: Monday, 25 February 2019 at 11.06
> > To: Tuukka Turunen <tuukka.turunen at qt.io>
> > Cc: Bernhard B <schluchti at gmail.com>, "interestqt-project. org" <interest at qt-project.org>
> > Subject: Re: [Interest] Fwd: vs. Flutter
> >
> > Tukka,
> >
> > I don't think that there is a single Mobile user that finds your reply adequate.
> >
> > It sounds like you're dragging Mobile users along. We need a specific mobile effort to add those mobile specific APIs the platform should have. Without these APIs, my organization will not be able to justify continued usage of Qt. I have to continually defend our selection of Qt. I've never spoken to someone who was happy to have to use Qt. Xamarin, Flutter, and ReactNative are what other developers want to use. I cannot expect to continue to win this fight as Qt falls behind.
> >
> >
> > I'm not the only one. I'm just the Squeakiest wheel. I can't really justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No transparent pricing) after spending $3000 on Qt.
> >
> > I'm begging you to add mobile APIs for:
> > - Device Hardware Control
> > -- Device Button Integration (volume, etc)
> > -- Display Brightness
> > -- Volume Control
> > -- Screen Control (Full Screen/ Nav Buttons, Wake Lock)
> > - Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain point)
> > - iOS NFC (starts at iPhone 7, iOS 10)
> >
> > These all might seem "not that hard", until you consider I have to do it for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, Java) This is a huge pain point, considering that is the fundamental problem that Qt claims solve. Except it doesn't... on Mobile. It's not like I'm asking for bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 2013 with Qt 5.2. In the 5 years since, none of the above have made it in and those are pretty basic features. Since that time there were some early iOS accessibilty additions and Android service capabilty. That's it.
> >
> > I'm not asking for every possible mobile API to be supported, just a 80/20. Other developers have their own needs, and I'm in favor of us together coming up with that list, and having Qt commit to the top item(s) each release. That's what I mean when I say I want a transparent roadmap for mobile.
> >
> >
> >
> > Sent: Monday, February 25, 2019 at 3:20 AM
> > From: "Tuukka Turunen" <tuukka.turunen at qt.io>
> > To: "Bernhard B" <schluchti at gmail.com>, "interestqt-project. org" <interest at qt-project.org>
> > Subject: Re: [Interest] Fwd: vs. Flutter
> > Hi,
> >
> > I focused mainly in the tooling and cross-platform features in the roadmap blog post. There are other items done as well – more than what reasonably fits into a post. Mobile is an area where we are making constant development, just like we do on desktop and embedded.
> >
> > Currently the biggest new investment goes towards tooling and 3D – both of which have some benefits for mobile as well. This of course eats some development capacity away from other things, but it does not mean nothing else would be done.
> >
> > Many of our desktop and embedded users also address mobile – in addition to those who address mobile only (or start with mobile). That is the beauty of the cross-platform, with a growing number of users deploying to mobile.
> >
> > Yours,
> >
> > Tuukka
> >
> > From: Interest <interest-bounces at qt-project.org> on behalf of Bernhard B <schluchti at gmail.com>
> > Date: Friday, 22 February 2019 at 14.28
> > To: "interestqt-project. org" <interest at qt-project.org>
> > Subject: Re: [Interest] Fwd: vs. Flutter
> >
> > Many thanks to Tuukka for the Qt Roadmap 2019 blog post (https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.qt.io_blog_2019_02_22_qt-2Droadmap-2D2019_&d=DwIGaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=81ZrscQ2yIyG6ANaI07JBq6GmZkaYdjZEl0tfKL-7tQ&m=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=cuOx16jORxiK5MX1A8nW4DjA7XVjmr66bnNYV7cI-pY&e=) - very much appreciated!
> >
> > As the mobile part was not explicitly mentioned, I assume that it won't be a focusing area for 2019 then? :/
> >
> > Jean-Michaël Celerier <jeanmichael.celerier at gmail.com<mailto:jeanmichael.celerier at gmail.com>> schrieb am Fr., 22. Feb. 2019, 12:09:
> > > They even included, scripts to build the app. I'm not sure you have to go quite that far to be compliant, but awesome nevertheless.
> >
> > You explicitely have to:
> >
> > LGPLv3 4. e): Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)
> >
> > And the corresponding GPL part (section 6, emphasis mine) :
> >
> > The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.
> >
> >
> >
> > On Fri, Feb 22, 2019 at 11:55 AM René Hansen <renehh at gmail.com<mailto:renehh at gmail.com>> wrote:
> >
> > On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, <jeanmichael.celerier at gmail.com<mailto:jeanmichael.celerier at gmail.com>> wrote:
> > Cisco did it with an app that uses gstreamer (which is under LGPL) : https://urldefense.proofpoint.com/v2/url?u=https-3A__itunes.apple.com_ua_app_cisco-2Djabber_id467192391-3Fmt-3D8&d=DwIGaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=81ZrscQ2yIyG6ANaI07JBq6GmZkaYdjZEl0tfKL-7tQ&m=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=jK-sUDRpXmYx4I3_7Sszx6_jtj82INPjf1dcmyPb_mU&e=.
> > They send it on request, with the proprietary part in a static lib (see at the end here :
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_GStreamer_gst-2Dplugins-2Dgood_blob_master_README.static-2Dlinking&d=DwIGaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=81ZrscQ2yIyG6ANaI07JBq6GmZkaYdjZEl0tfKL-7tQ&m=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=mdK0jMt8dAi2AgnWNH143zYqOT6CiDwH5RAH2LFIyKA&e=
> > )
> >
> > That is really cool. They even included, scripts to build the app. I'm not sure you have to go quite that far to be compliant, but awesome nevertheless. Maybe someone can clarify this further. I.e. Are you responsible for providing a, or instructions for creating a, working build environment, in order to be LGPL compliant.
> >
> >
> > Best,
> > Jean-Michaël
> >
> > On Thu, Feb 21, 2019 at 6:07 PM Sylvain Pointeau <sylvain.pointeau at gmail.com<mailto:sylvain.pointeau at gmail.com>> wrote:
> > Do you have one example of someone who put a LGPL app in the app store and provided the binary object files?
> >
> > On Thu, Feb 21, 2019 at 3:58 PM Julius Bullinger <julius.bullinger at gmail.com<mailto:julius.bullinger at gmail.com>> wrote:
> > On 21.02.2019 15:44, Christian Gagneraud wrote:
> > > Qt is free (on mobile), free as in liberty, as long as your
> > > application is free, as in liberty.
> > > That's basic (L)GPL rules.
> > >
> > > Now there's the business rules:
> > > If you want your (mobile) app to be non-free (as in proprietary), then
> > > you'll have to pay the Qt company for that. Disregarding the fact that
> > > you want to make money or not.
> >
> > Please do not spread this misinformation! As long as you adhere to the
> > terms of LGPL, you can create non-free, proprietary and closed apps with
> > Qt (or any other LGPL library for that matter). You only need to make
> > sure that the user can replace all LGPL parts with their own builds.
> >
> > The fact that the mobile OS's and app stores make it exceptionally hard
> > to do that is not an issue with the license terms. If you find a way
> > that enables the user to replace LGPL parts (for example by dynamic
> > linking or by making all object files and linking instructions available
> > on request), that's perfectly valid and legal.
> >
> > _That_ is a basic LGPL rule.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tldrlegal.com_license_gnu-2Dlesser-2Dgeneral-2Dpublic-2Dlicense-2Dv2.1-2D-28lgpl-2D2.1-29&d=DwIGaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=81ZrscQ2yIyG6ANaI07JBq6GmZkaYdjZEl0tfKL-7tQ&m=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=wJ2XxCZ09pvosp0UfNTCftmtdbfQpC9_oD_G0aj6aiI&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tldrlegal.com_license_gnu-2Dlesser-2Dgeneral-2Dpublic-2Dlicense-2Dv3-2D-28lgpl-2D3-29&d=DwIGaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=81ZrscQ2yIyG6ANaI07JBq6GmZkaYdjZEl0tfKL-7tQ&m=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=lMNRyimcDoSRLXSGZcv4yc44mEQ-V_HtR-24TIay5Wg&e=
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org<mailto:Interest at 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=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=i5aaZmT7-cT9tdypu01W_Y43KnG1T2UhmmJyJl2fsBo&e=
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org<mailto:Interest at 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=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=i5aaZmT7-cT9tdypu01W_Y43KnG1T2UhmmJyJl2fsBo&e=
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org<mailto:Interest at 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=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=i5aaZmT7-cT9tdypu01W_Y43KnG1T2UhmmJyJl2fsBo&e=
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org<mailto:Interest at 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=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=i5aaZmT7-cT9tdypu01W_Y43KnG1T2UhmmJyJl2fsBo&e=
> > _______________________________________________ Interest mailing list Interest at 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=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=i5aaZmT7-cT9tdypu01W_Y43KnG1T2UhmmJyJl2fsBo&e=
> >
>
>
>
_______________________________________________
Interest mailing list
Interest at 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=gGBPBAvYL4BWl0AGYXbGj872UZbNcjjhnHlSIj_w434&s=i5aaZmT7-cT9tdypu01W_Y43KnG1T2UhmmJyJl2fsBo&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.
More information about the Interest
mailing list