[Interest] Fwd: vs. Flutter

Mon Feb 25 23:06:11 CET 2019

> 1. "Access to media gallery on android" ? If you're taking pictures in Qt
and want them to appear in the gallery, you currently have to save them to
the gallery and reboot the device. Or implement a Broadcast message to tell
Android to scan/add the image.  Yet another thing Qt is missing on
mobile...

Not only saving an image to the gallery, but also opening the native
android image gallery to select an image. I think I've implemented the
necessary JNI calls while working with Qt 5.9.x..so maybe newer Qt versions
have that already covered.

> Sensors (accelerometer) work. In fact I regularly use most of the
sensors.

thanks, wasn't aware of that!

>  Can you elaborate on your keychain needs?

I use the keychain primarily for storing sensitive data. e.q: If the user
authenticates itself against a web service, I store the returned access
token in the keystore (android) resp. keychain (iOs).

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

>
> 1. "Access to media gallery on android" ? If you're taking pictures in Qt
> and want them to appear in the gallery, you currently have to save them to
> the gallery and reboot the device. Or implement a Broadcast message to tell
> Android to scan/add the image.  Yet another thing Qt is missing on mobile...
>
> 2. Sensors (accelerometer) work. In fact I regularly use most of the
> sensors.
>
> 3. Can you elaborate on your keychain needs?
>
> *Sent:* Monday, February 25, 2019 at 2:48 PM
> *From:* "Bernhard B" <schluchti at gmail.com>
> *To:* "Jason H" <jhihn at gmx.com>
> *Cc:* "Tuukka Turunen" <tuukka.turunen at qt.io>, "interestqt-project. org" <
> interest at qt-project.org>
> *Subject:* Re: [Interest] Fwd: vs. Flutter
> 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/2e44e27c/attachment.html>