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" <jh...@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.turu...@qt.io>
    > To: "Jason H" <jh...@gmx.com>
    > Cc: "Bernhard B" <schluc...@gmail.com>, "interestqt-project. org" 
<interest@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 <jh...@gmx.com>
    > Date: Monday, 25 February 2019 at 11.06
    > To: Tuukka Turunen <tuukka.turu...@qt.io>
    > Cc: Bernhard B <schluc...@gmail.com>, "interestqt-project. org" 
<interest@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.turu...@qt.io>
    > To: "Bernhard B" <schluc...@gmail.com>, "interestqt-project. org" 
<interest@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-boun...@qt-project.org> on behalf of Bernhard B 
<schluc...@gmail.com>
    > Date: Friday, 22 February 2019 at 14.28
    > To: "interestqt-project. org" <interest@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.celer...@gmail.com<mailto:jeanmichael.celer...@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 
<ren...@gmail.com<mailto:ren...@gmail.com>> wrote:
    > 
    > On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, 
<jeanmichael.celer...@gmail.com<mailto:jeanmichael.celer...@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.point...@gmail.com<mailto:sylvain.point...@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.bullin...@gmail.com<mailto:julius.bullin...@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@qt-project.org<mailto:Interest@qt-project.org>
    > https://lists.qt-project.org/listinfo/interest
    > _______________________________________________
    > Interest mailing list
    > Interest@qt-project.org<mailto:Interest@qt-project.org>
    > https://lists.qt-project.org/listinfo/interest
    > _______________________________________________
    > Interest mailing list
    > Interest@qt-project.org<mailto:Interest@qt-project.org>
    > https://lists.qt-project.org/listinfo/interest
    > _______________________________________________
    > Interest mailing list
    > Interest@qt-project.org<mailto:Interest@qt-project.org>
    > https://lists.qt-project.org/listinfo/interest
    > _______________________________________________ Interest mailing list 
Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
    >
    

_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Reply via email to