[Interest] Fwd: vs. Flutter

Mon Feb 25 20:48:12 CET 2019

definitely a +1 from my side.

I totally get that there are limited resources and therefore management has
to focus on some parts, but if I just look at the Qt mobile functionality
(and blend away everything else), I have to agree with Jason. Fortunately I
am in a position where I do not "depend" on Qt in any way - I am just a
hobby developer that likes to tinker around. So, if it turns out that the
mobile development halts, I'll probably migrate my apps away from Qt at
some point and/or use a different framework for new projects. But I guess
that's a bit more difficult for developers that earn a living with their Qt
apps - porting away from Qt then will be a huge pain (and most often not
worth it from a business point of view, unless it gets unbearable).

The main reason, why I am still with Qt on mobile is, that I know most of
Qt's quirks and that I really LOVE QML. Another huge plus is, that I've
grown a pretty solid set of
device dependend helper tools/functionalities over the years. Namely:

- Notifications (GCM)
- Hardware buttons
- Vibration
- Sensors (Accelerometer)
- Screen Control (keep screen on)
- Keystore/Keychain integration to store credentials
- Access to media gallery on android (I have to check, but I _think_ that
functionality is now part of Qt 5.13; at least according to
https://wiki.qt.io/New_Features_in_Qt_5.13)

If I wouldn't have those ready at my fingertips, I am not really sure
whether I would choose Qt again...
I also found it pretty hard (I would almost say impossible) to convince my
friends to give Qt a shot. No matter how good Qt's declarative language is,
there are certain functionalities that every mobile app developer expects
from a framework and unfortunately, Qt's missing quite a few of them :/

Cheers,
Bernhard

Am Mo., 25. Feb. 2019 um 17:06 Uhr schrieb Jason H <jhihn at gmx.com>:

> 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://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/) - 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> 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> wrote:
>
>
>
> On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, <
> jeanmichael.celerier at gmail.com> wrote:
>
> Cisco did it with an app that uses gstreamer (which is under LGPL) :
> https://itunes.apple.com/ua/app/cisco-jabber/id467192391?mt=8.
>
> They send it on request, with the proprietary part in a static lib (see at
> the end here :
>
>
> https://github.com/GStreamer/gst-plugins-good/blob/master/README.static-linking
>
> )
>
>
>
> 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> 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> 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://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)
>
> https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
> _______________________________________________ Interest mailing list
> Interest at 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/20190225/66486122/attachment.html>