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
