Re: [Interest] Fwd: vs. Flutter
Good finds Markus! This makes me insanely happy. I've filed at least a bug on notifications before, but it went nowhere. But 74049 at least acknowledges that there's a difference from where it is, to where it should be. > Sent: Thursday, February 28, 2019 at 1:39 AM > From: "Markus Maier" > To: interest > Subject: Re: [Interest] Fwd: vs. Flutter > > I stumbled upon these two EPIC's in JIRA today - the first was > recently updated, the second one is two days old now: > https://bugreports.qt.io/browse/QTBUG-72086 > https://bugreports.qt.io/browse/QTBUG-74049 > > So while there is currently no commitment to start a bigger > development task, it seems that this thread here triggered some active > research inside TQtC how mobile support can be improved. Which is a > good thing IMHO. > ___ > 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
Re: [Interest] Fwd: vs. Flutter
I stumbled upon these two EPIC's in JIRA today - the first was recently updated, the second one is two days old now: https://bugreports.qt.io/browse/QTBUG-72086 https://bugreports.qt.io/browse/QTBUG-74049 So while there is currently no commitment to start a bigger development task, it seems that this thread here triggered some active research inside TQtC how mobile support can be improved. Which is a good thing IMHO. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
> Sent: Wednesday, February 27, 2019 at 2:59 PM > From: "Richard Weickelt" > To: interest@qt-project.org > Subject: Re: [Interest] Fwd: vs. Flutter > > > 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. > The company is a joint stock company with the sole purpose of making as much > profit as possible and filling the pockets of its owners. So this is the best reply so far. I just wish it was more than speculation. > I guess someone in TQtC has done the math and came to the conclusion that > they could make much more profit by investing their limited resources in > growth markets like Industrial & Automotive. Mobile apps are probably a > mature business and the marketing department doesn't expect any more growth > there, at least no growth in their market share. This means that the cow > will be milked and only maintained. A very valid point. But there's a bit of chicken and egg. They are a mature business, but everyone expects iOS and Android availability at launch. Qt is the best API (so far) to deliver this. However there is a bit of chicken and egg. If you build it, they will come, but you want to know that they will come before you build it. QML is dead-simple and the best way to make an app, but then you run into these missing APIs and you're in a world of hurt. One moment cross-platform as can be, playign video, then writing ObjectiveC to keep the screen from locking. It's a combination of both extremes. > In addition, TQtC may not be able to keep up with the big players who are > constantly pushing new programming languages and frameworks into the market. > Simply because the big players have a multiple of manpower and don't have to > earn any money with their frameworks. Google & co earn a lot of money with > every sold app anyway. TQtC doesn't have this opportunity. This really isn't how I see it. The platforms have reached maturity and what we're after is only the missing bits - device control and notifications - that have been standard on smart phones for 10+ years. I don't expect that anyone expects Qt to be cutting edge. > But what I can recommend, and this is the special thing about TQtC: Submit > patches because the product is open source and the developers are very > responsive. Stories in JIRA with suggestions and wishes are in my experience > like write accesses to /dev/null. You have to do it yourself. Once you've > overcome this hurdle, you usually get a decent code review and constructive > feedback. > > Of course, this is all pure speculation. ;-) And reasonable speculation at that. I just I wish it weren't, and we could have clarity on this. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
+2 (if it does matter) Sent from Mailspring (https://link.getmailspring.com/link/6fa2ac51-f627-413f-8df1-fe1a8f21c...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=aW50ZXJlc3RAcXQtcHJvamVjdC5vcmc%3D), the best free email app for work On Feb 27 2019, at 11:23 pm, Nelson, Michael wrote: > +1 > > Thank you Jason for being so vocal and expressing the concerns of other > invested users so well. > Mike > -Original Message- > From: Interest On Behalf Of Jason H > Sent: Wednesday, February 27, 2019 1:35 PM > To: Tuukka Turunen > Cc: interestqt-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 > rathe
Re: [Interest] Fwd: vs. Flutter
+1 Thank you Jason for being so vocal and expressing the concerns of other invested users so well. Mike -Original Message- From: Interest On Behalf Of Jason H Sent: Wednesday, February 27, 2019 1:35 PM To: Tuukka Turunen Cc: interestqt-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" > To: "Jason H" > Cc: "Bernhard B" ,
Re: [Interest] Fwd: vs. Flutter
> 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. The company is a joint stock company with the sole purpose of making as much profit as possible and filling the pockets of its owners. I guess someone in TQtC has done the math and came to the conclusion that they could make much more profit by investing their limited resources in growth markets like Industrial & Automotive. Mobile apps are probably a mature business and the marketing department doesn't expect any more growth there, at least no growth in their market share. This means that the cow will be milked and only maintained. In addition, TQtC may not be able to keep up with the big players who are constantly pushing new programming languages and frameworks into the market. Simply because the big players have a multiple of manpower and don't have to earn any money with their frameworks. Google & co earn a lot of money with every sold app anyway. TQtC doesn't have this opportunity. But what I can recommend, and this is the special thing about TQtC: Submit patches because the product is open source and the developers are very responsive. Stories in JIRA with suggestions and wishes are in my experience like write accesses to /dev/null. You have to do it yourself. Once you've overcome this hurdle, you usually get a decent code review and constructive feedback. Of course, this is all pure speculation. ;-) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
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" > To: "Jason H" > Cc: "Bernhard B" , "interestqt-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 inves
Re: [Interest] Fwd: vs. Flutter
> I guess that amongst mobile developers this number is higher than for C++ yeah right, but I am not sure whether the majority of Qt developers (the target group) want to deal with Java/Objective C. e.q: I know quite a few C++ developers who hate Java with a passion. But I don't want to start a language war here, so please see the generalized statement as that what it is: a generalized statement ;-) I am wondering whether I can help to improve the current situation somehow. I've never contributed to Qt before, but I think with a bit of help from the community and some experienced developers I might be able to make some small improvements. But what happens with the feature once it is implemented? Who will maintain the feature and fix bugs? I think especially at the beginning (platform specific) bugs will arise. Ideally I guess, those bugs should be fixed by the person who implemented the feature (as he/she knows the code best). But in my case, even if I find time to contribute some small improvements, I probably won't be able to maintain them (I am already involved in too many open source projects). What happens with the code then? Will it be maintained by someone else? I am a bit afraid that we eventually end up in the same situation, even if "non-Qt core developers" contribute something. The only difference is then, that the feature is broken instead of missing. I am not sure whether that's any better..(I remember that I've tried to enable the android selection handles immediately after they got introduced. Unfortunately I stumbled across some nasty bugs which I couldn't resolve without patching and rebuilding Qt. So I ended up deactivating the selection handles again. Although the functionality was already there (and almost working), it took a few Qt patch releases until those issues got fixed). Cheers, Bernhard Konstantin Tokarev schrieb am Mi., 27. Feb. 2019, 18:34: > > > 27.02.2019, 18:23, "Jason H" : > >Who knows Objective C and Java? Not many. > > I guess that amongst mobile developers this number is higher than for C++ > > -- > Regards, > Konstantin > > ___ > 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
Re: [Interest] Fwd: vs. Flutter
27.02.2019, 18:23, "Jason H" : >Who knows Objective C and Java? Not many. I guess that amongst mobile developers this number is higher than for C++ -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
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" 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"
> To: "Jason H"
> Cc: "Bernhard B" , "interestqt-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
> Date: Monday, 25 February 2019 at 11.06
> To: Tuukka Turunen
> Cc: Bernhard B , "interestqt-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,
Re: [Interest] Fwd: vs. Flutter
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" > To: "Jason H" > Cc: "Bernhard B" , "interestqt-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 > Date: Monday, 25 February 2019 at 11.06 > To: Tuukka Turunen > Cc: Bernhard B , "interestqt-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" > To: "Bernhard B" , "interestqt-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
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 Date: Monday, 25 February 2019 at 11.06 To: Tuukka Turunen Cc: Bernhard B , "interestqt-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" To: "Bernhard B" , "interestqt-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 on behalf of Bernhard B Date: Friday, 22 February 2019 at 14.28 To: "interestqt-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 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 App
Re: [Interest] Fwd: vs. Flutter
> 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 : > > 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" > *To:* "Jason H" > *Cc:* "Tuukka Turunen" , "interestqt-project. org" < > interest@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 : > >> 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
Re: [Interest] Fwd: vs. Flutter
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" To: "Jason H" Cc: "Tuukka Turunen" , "interestqt-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 <jh...@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.turu...@qt.io> To: "Bernhard B" <schluc...@gmail.com>, "interestqt-project. org" <interest@qt-project.org> Subject: Re: [Interest] Fwd: vs. Flutter Hi,
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 : > 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" > *To:* "Bernhard B" , "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 > els
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" To: "Bernhard B" , "interestqt-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 on behalf of Bernhard B Date: Friday, 22 February 2019 at 14.28 To: "interestqt-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> 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
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 on behalf of Bernhard B Date: Friday, 22 February 2019 at 14.28 To: "interestqt-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 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 mailto:ren...@gmail.com>> wrote: On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, 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 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 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
Re: [Interest] Fwd: vs. Flutter
> On 22 Feb 2019, at 13:24, Bernhard B wrote: > > 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? :/ Well-bounded features like notifications can still be done if somebody finds the time to do it. I think that one is good to get done, whether it’s on the roadmap or not, as a cross-platform feature. I’m kindof interested because I worked on Linux D-Bus support for QSystemTrayIcon a while back, and I think that’s related to desktop notifications. I think someone else is interested in working on it too. But I won’t realistically get around to it anytime soon unless a good reason comes up (like having it be a priority either for the company or for a personal project). ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
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 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 wrote: > >> >> >> On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, < >> 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> 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> 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 > 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 >>> >> ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mai
Re: [Interest] Fwd: vs. Flutter
> 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 wrote: > > > On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, < > 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> 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> 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 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 >> > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, < 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> 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> 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 >>> 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 > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
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 ) Best, Jean-Michaël On Thu, Feb 21, 2019 at 6:07 PM Sylvain Pointeau 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> 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 >> 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
Re: [Interest] Fwd: vs. Flutter
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 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 > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
Well, this was my question here. What makes you think, you violate the LGPL in this case? >You *cannot* publish (for free or at a cost) Qt based proprietary SW >on Google play store w/o a Qt license. It would violate the LGPL. The >Qt license is a (costly) LGPL substitute. > >Chris > > > >> >> /René >> >> >> On Thu, 21 Feb 2019 at 14:50 Sylvain Pointeau > wrote: >>> >>> On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau > wrote: Qt is free on desktop, but it is not free on mobile, which is a >real showstopper for me and many others. Le mar. 19 févr. 2019 à 20:12, ich a écrit : > > Qt is free, too. >>> >>> >>> I received few personal emails to ask me why am I writing that Qt is >not free on mobile. >>> >>> I am sorry but this is the message from the Qt company, please show >me one official statement that Qt is free to use on mobile. >>> I would be really glad and finally use Qt instead of looking for >alternatives. >>> >>> Best regards, >>> Sylvain >>> >>> >>> ___ >>> 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 >___ >Interest mailing list >Interest@qt-project.org >https://lists.qt-project.org/listinfo/interest -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
On Fri, 22 Feb 2019 at 03:56, Julius Bullinger 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. Oops, you are right. My mistake. And the key point is the acquisition of Qt by Nokia. Trolltech used to publish Qt as GPL, once acquired by Nokia, Qt became LGPL. And this LGPL stuck when Digia aquired Qt from Nokia, AFAIU. (i've lost track of who "owns" Qt by now, so many intermediate companies) So yes, I agree. you can sell Qt based proprietary SW on google play store w/o a Qt license. You still have to respect the Qt LGPL license, that is, if you modify it, you need to make the source of your custom version of Qt openly available. And this doesn't apply to you own app, thanks to the 'L' in LGPL. Chris > > 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 > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
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 https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
On Fri, 22 Feb 2019 at 02:53, René Hansen wrote: > > You're reversing the burden of proof here. Where have Qt stated that it is > non-free for mobile? > > The licensing terms are the same no matter the platform; Qt is LGPL or > Commercial. It's up to you to adhere to whichever license you choose to > utilise. > --- Free beer vs Freedom vs Business --- 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. Makes sense to me. Open source is a take/give philosophy, you cannot use open source software to produce non-open-source software. If your software is not open-source, then you need to $$$ a license, that's the deal, that's the business model. To add to the confusion, you can sell open-source software too, if your buyer is not aware (or can't bother) that she/he can build it her/himself, she/he will be happy to buy a binary produced from an open-source piece of software... You *can* publish (for free or at a cost) Qt based open-source SW on android play store without having to pay the Qt company. As long as you respect the (L)GPL license, period. You *cannot* publish (for free or at a cost) Qt based proprietary SW on Google play store w/o a Qt license. It would violate the LGPL. The Qt license is a (costly) LGPL substitute. The Qt project is open-source, The Qt company is not, and through payment, the Qt company allows you to be closed-source. The fact that you might want to make money out of this process is irrelevant. Chris > > /René > > > On Thu, 21 Feb 2019 at 14:50 Sylvain Pointeau > wrote: >> >> On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau >> wrote: >>> >>> Qt is free on desktop, but it is not free on mobile, which is a real >>> showstopper for me and many others. >>> >>> Le mar. 19 févr. 2019 à 20:12, ich a écrit : Qt is free, too. >> >> >> I received few personal emails to ask me why am I writing that Qt is not >> free on mobile. >> >> I am sorry but this is the message from the Qt company, please show me one >> official statement that Qt is free to use on mobile. >> I would be really glad and finally use Qt instead of looking for >> alternatives. >> >> Best regards, >> Sylvain >> >> >> ___ >> 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 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
So there are only three licences: LGPL Commercial Commercial Runtime (Boot2Qt) IANAL, but the dynamic/static linking debate is not even settled, even in court. I would say that the spirit of LGPL and existing precedent is that under LGPL you can't modify Qt without releasing it. If you want to modify Qt and not release it, then commerical is the way to go. GPL parts adhere to the dynamic linking which is regarded as permissible by Linus Torvalds, who I consider a subject matter expert. IANAL, YMMV, WYGIWYS, WYSIWYG, etc. Sent: Thursday, February 21, 2019 at 9:01 AM From: "ich" To: interest@qt-project.org, "Sylvain Pointeau" , "Qt Project" Subject: Re: [Interest] Fwd: vs. Flutter Thou shall not use sellers opinion as legal correct advice:) qt.io tends to hide facts and even post wrong "facts"... Am February 21, 2019 1:49:21 PM UTC schrieb Sylvain Pointeau : On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau <sylvain.point...@gmail.com> wrote: Qt is free on desktop, but it is not free on mobile, which is a real showstopper for me and many others. Le mar. 19 févr. 2019 à 20:12, ich <a...@golks.de> a écrit : Qt is free, too. I received few personal emails to ask me why am I writing that Qt is not free on mobile. I am sorry but this is the message from the Qt company, please show me one official statement that Qt is free to use on mobile. I would be really glad and finally use Qt instead of looking for alternatives. Best regards, Sylvain -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___ 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
Re: [Interest] Fwd: vs. Flutter
Thou shall not use sellers opinion as legal correct advice:) qt.io tends to hide facts and even post wrong "facts"... Am February 21, 2019 1:49:21 PM UTC schrieb Sylvain Pointeau : >On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau > >wrote: > >> Qt is free on desktop, but it is not free on mobile, which is a real >> showstopper for me and many others. >> >> Le mar. 19 févr. 2019 à 20:12, ich a écrit : >> >>> Qt is free, too. >>> >> >I received few personal emails to ask me why am I writing that Qt is >not >free on mobile. > >I am sorry but this is the message from the Qt company, please show me >one >official statement that Qt is free to use on mobile. >I would be really glad and finally use Qt instead of looking for >alternatives. > >Best regards, >Sylvain -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
As you said, look at the license:) You may git clone qt, read the LGPL license, accept it, and deploy your Android app. Just as you do with other LGPL code. What else official do you need? Yesterday i found worth reading: https://wiki.qt.io/Licensing-talk-about-mobile-platforms Am February 21, 2019 1:49:21 PM UTC schrieb Sylvain Pointeau : >On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau > >wrote: > >> Qt is free on desktop, but it is not free on mobile, which is a real >> showstopper for me and many others. >> >> Le mar. 19 févr. 2019 à 20:12, ich a écrit : >> >>> Qt is free, too. >>> >> >I received few personal emails to ask me why am I writing that Qt is >not >free on mobile. > >I am sorry but this is the message from the Qt company, please show me >one >official statement that Qt is free to use on mobile. >I would be really glad and finally use Qt instead of looking for >alternatives. > >Best regards, >Sylvain -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
You're reversing the burden of proof here. Where have Qt stated that it is non-free for mobile? The licensing terms are the same no matter the platform; Qt is LGPL or Commercial. It's up to you to adhere to whichever license you choose to utilise. /René On Thu, 21 Feb 2019 at 14:50 Sylvain Pointeau wrote: > On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau < > sylvain.point...@gmail.com> wrote: > >> Qt is free on desktop, but it is not free on mobile, which is a real >> showstopper for me and many others. >> >> Le mar. 19 févr. 2019 à 20:12, ich a écrit : >> >>> Qt is free, too. >>> >> > I received few personal emails to ask me why am I writing that Qt is not > free on mobile. > > I am sorry but this is the message from the Qt company, please show me one > official statement that Qt is free to use on mobile. > I would be really glad and finally use Qt instead of looking for > alternatives. > > Best regards, > Sylvain > > > ___ > 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
Re: [Interest] Fwd: vs. Flutter
On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau wrote: > Qt is free on desktop, but it is not free on mobile, which is a real > showstopper for me and many others. > > Le mar. 19 févr. 2019 à 20:12, ich a écrit : > >> Qt is free, too. >> > I received few personal emails to ask me why am I writing that Qt is not free on mobile. I am sorry but this is the message from the Qt company, please show me one official statement that Qt is free to use on mobile. I would be really glad and finally use Qt instead of looking for alternatives. Best regards, Sylvain ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
Qt creator does it for you, just add whatever APIs you need (Android SDK, NDK) or xCode and select the plaftorm above the big Run button in QtCreator.
Launch the Maintence tool, download Qt for the target platform
AFAIK, it is free on Mobile. However... as I've repeatedly stated that I continually find bugs/parity issues between mobile platforms. Having a support contract really helps in this regard. The diffs are not large, but if you're new to a platform, you might not find it as friendly as you'd like. I routinely hack Obj-C and Java to make things work in Qt that should "just work". But getting clued into these foreign platforms can be frustrating. You've got to know a little "too much" about the target platform - For iOS it's your Application Delegate and Obj-C, on Android it's the Activity and JNI.
But most simple apps are as easy as just changing the build target. When it doesn't work, I file a bug. Example: You can take pictures (Camera.capture()) on iOS without a VideoOutput, but you can't do that in Android so you create an invisible one as a work-around. https://bugreports.qt.io/browse/QTBUG-73237 Or that audioRoles are not implemented on the platform. https://bugreports.qt.io/browse/QTBUG-73316 (iOS)
https://bugreports.qt.io/browse/QTBUG-73119 (FIXED, Android) (iOS has a global autio context, so this is less of an issue there, but Android does not, so it's a bigger issue) but the whole diff for Android was 445 lines which is not much. (and the bulk of those lines is enumerating the various audioRole mapping to/from Android)
Sometimes it's just not possible (no iOS API for AmbientLight sensor)
As long as you're not digging too much into the platform Qt *will* *just work*. :-)
Sent: Tuesday, February 19, 2019 at 8:39 PM
From: "ich"
To: No recipient address
Cc: interest@qt-project.org
Subject: Re: [Interest] Fwd: vs. Flutter
OK, i've no idea about how to deploy to mobile devices,
but what makes you think its not free?
Am February 19, 2019 7:30:23 PM UTC schrieb Sylvain Pointeau :
Qt is free on desktop, but it is not free on mobile, which is a real showstopper for me and many others.
Le mar. 19 févr. 2019 à 20:12, ich <a...@golks.de> a écrit :
Qt is free, too.
Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau <sylvain.point...@gmail.com>:
I cannot get it copied in the email, but the code in the section get started has no "new" but I agree with you that it is not "declarative"
The positive points about flutter is that it is free, and intellij (IDEA) is so great.
However, it feels too young, and limited to mobile (some are saying that the desktop is coming, but nothing concrete yet)
react native (via react xp) seems to be a better alternative for now.
Best regards,
Sylvain
Le mar. 19 févr. 2019 à 19:43, Jason H <jh...@gmx.com> a écrit :
It's still on the home page: https://flutter.io/ "Fast Development"
I operate on the "read at least the first page" premise. That whatever they think is most important should be found there.
But losing new doesn't really change my opinion of if it's declarative or not.
Thanks for the update/correction though.
Sent: Tuesday, February 19, 2019 at 1:34 PM
From: "Sylvain Pointeau" <sylvain.point...@gmail.com>
To: "Qt Project" <interest@qt-project.org>
Subject: [Interest] Fwd: vs. Flutter
the "new" is now removed in dart 2.0 so you example is outdated.
-- Message transféré -
De : Jason H <jh...@gmx.com>
Date : mar. 19 févr. 2019 à 19:25
Objet : Re: [Interest] vs. Flutter
À : Bernhard B <schluc...@gmail.com>
CC : <inter...@lists.qt-project.org>
I'm in your offtopic camp.
Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly.
Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page:
Widget build(BuildContext context) {
return new Scaffold (
appBar: new AppBar ( title: new Text (widget.title), ),
body: new Center (
child: new Text( "Button clicked" ...
),
),
}
Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages.
Sent: Tuesday, February 19, 2019 at 12:55 PM
From: "Bernhard B" <schlu
Re: [Interest] Fwd: vs. Flutter
OK, i've no idea about how to deploy to mobile devices,
but what makes you think its not free?
Am February 19, 2019 7:30:23 PM UTC schrieb Sylvain Pointeau
:
>Qt is free on desktop, but it is not free on mobile, which is a real
>showstopper for me and many others.
>
>Le mar. 19 févr. 2019 à 20:12, ich a écrit :
>
>> Qt is free, too.
>>
>> Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau <
>> sylvain.point...@gmail.com>:
>>>
>>> I cannot get it copied in the email, but the code in the section get
>>> started has no "new" but I agree with you that it is not
>"declarative"
>>>
>>> The positive points about flutter is that it is free, and intellij
>(IDEA)
>>> is so great.
>>> However, it feels too young, and limited to mobile (some are saying
>that
>>> the desktop is coming, but nothing concrete yet)
>>>
>>> react native (via react xp) seems to be a better alternative for
>now.
>>>
>>> Best regards,
>>> Sylvain
>>>
>>>
>>> Le mar. 19 févr. 2019 à 19:43, Jason H a écrit :
>>>
>>>> It's still on the home page: https://flutter.io/ "Fast Development"
>>>> I operate on the "read at least the first page" premise. That
>whatever
>>>> they think is most important should be found there.
>>>>
>>>> But losing new doesn't really change my opinion of if it's
>declarative
>>>> or not.
>>>>
>>>> Thanks for the update/correction though.
>>>>
>>>>
>>>> *Sent:* Tuesday, February 19, 2019 at 1:34 PM
>>>> *From:* "Sylvain Pointeau"
>>>> *To:* "Qt Project"
>>>> *Subject:* [Interest] Fwd: vs. Flutter
>>>> the "new" is now removed in dart 2.0 so you example is outdated.
>>>>
>>>>
>>>> -- Message transféré -
>>>> De : Jason H
>>>> Date : mar. 19 févr. 2019 à 19:25
>>>> Objet : Re: [Interest] vs. Flutter
>>>> À : Bernhard B
>>>> CC :
>>>>
>>>> I'm in your offtopic camp.
>>>> Everything is going Declarative. I really hate that web
>devevlopment
>>>> requires the use of HTML/CSS/JS (that's just client side) and some
>>>> Framework of the Month. The JavaScript kiddies love inventing
>frameworks
>>>> for fame and profit rather than picking one and making it better.
>>>> Fragmentation is rampant. On top of that JS is slow to change, it
>just
>>>> becomes a runtime that your flavor-of-the-month framework compiles
>down to,
>>>> well until WebAssembly.
>>>>
>>>> Rene, I don't understand why you don't declare Flutter Declarative?
>From
>>>> the Flutter home page:
>>>> Widget build(BuildContext context) {
>>>> return new Scaffold (
>>>> appBar: new AppBar ( title: new Text (widget.title), ),
>>>> body: new Center (
>>>> child: new Text( "Button clicked" ...
>>>> ),
>>>> ),
>>>> }
>>>>
>>>> Good luck typing 'new' and 'return' a lot. At least QML manages
>that for
>>>> you. QML is the sleekest of all the declarative languages.
>>>>
>>>>
>>>> *Sent:* Tuesday, February 19, 2019 at 12:55 PM
>>>> *From:* "Bernhard B"
>>>> *To:* "Bob Hood"
>>>> *Cc:* "René Hansen" , "Jason H" ,
>>>> inter...@lists.qt-project.org
>>>>
>>>> *Subject:* Re: [Interest] vs. Flutter
>>>> > I've been studying it for a while now, and I've decided that it
>will
>>>> likely be
>>>> my mobile development language. I love Qt to death for desktop,
>but I've
>>>> never been able to take to it's declarative approach. I know
>others
>>>> swear by
>>>> it, but it just never fit my brain waves for some reason.
>>>>
>>>>
>>>> I guess I am one of those persons, who absolutely LOVE Qt's
>declarative
>>>> language.
>>>> I like QML so much, that I even started looking for QML -> HTML/CSS
>>>> translators. While I really like QML,
>>>> I absolutely hate HTML and CSS (never got used to its quirks). I
>mean
>>>> there are some attempts like
>&
Re: [Interest] Fwd: vs. Flutter
Qt is free on desktop, but it is not free on mobile, which is a real
showstopper for me and many others.
Le mar. 19 févr. 2019 à 20:12, ich a écrit :
> Qt is free, too.
>
> Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau <
> sylvain.point...@gmail.com>:
>>
>> I cannot get it copied in the email, but the code in the section get
>> started has no "new" but I agree with you that it is not "declarative"
>>
>> The positive points about flutter is that it is free, and intellij (IDEA)
>> is so great.
>> However, it feels too young, and limited to mobile (some are saying that
>> the desktop is coming, but nothing concrete yet)
>>
>> react native (via react xp) seems to be a better alternative for now.
>>
>> Best regards,
>> Sylvain
>>
>>
>> Le mar. 19 févr. 2019 à 19:43, Jason H a écrit :
>>
>>> It's still on the home page: https://flutter.io/ "Fast Development"
>>> I operate on the "read at least the first page" premise. That whatever
>>> they think is most important should be found there.
>>>
>>> But losing new doesn't really change my opinion of if it's declarative
>>> or not.
>>>
>>> Thanks for the update/correction though.
>>>
>>>
>>> *Sent:* Tuesday, February 19, 2019 at 1:34 PM
>>> *From:* "Sylvain Pointeau"
>>> *To:* "Qt Project"
>>> *Subject:* [Interest] Fwd: vs. Flutter
>>> the "new" is now removed in dart 2.0 so you example is outdated.
>>>
>>>
>>> -- Message transféré -
>>> De : Jason H
>>> Date : mar. 19 févr. 2019 à 19:25
>>> Objet : Re: [Interest] vs. Flutter
>>> À : Bernhard B
>>> CC :
>>>
>>> I'm in your offtopic camp.
>>> Everything is going Declarative. I really hate that web devevlopment
>>> requires the use of HTML/CSS/JS (that's just client side) and some
>>> Framework of the Month. The JavaScript kiddies love inventing frameworks
>>> for fame and profit rather than picking one and making it better.
>>> Fragmentation is rampant. On top of that JS is slow to change, it just
>>> becomes a runtime that your flavor-of-the-month framework compiles down to,
>>> well until WebAssembly.
>>>
>>> Rene, I don't understand why you don't declare Flutter Declarative? From
>>> the Flutter home page:
>>> Widget build(BuildContext context) {
>>> return new Scaffold (
>>> appBar: new AppBar ( title: new Text (widget.title), ),
>>> body: new Center (
>>> child: new Text( "Button clicked" ...
>>> ),
>>> ),
>>> }
>>>
>>> Good luck typing 'new' and 'return' a lot. At least QML manages that for
>>> you. QML is the sleekest of all the declarative languages.
>>>
>>>
>>> *Sent:* Tuesday, February 19, 2019 at 12:55 PM
>>> *From:* "Bernhard B"
>>> *To:* "Bob Hood"
>>> *Cc:* "René Hansen" , "Jason H" ,
>>> inter...@lists.qt-project.org
>>>
>>> *Subject:* Re: [Interest] vs. Flutter
>>> > I've been studying it for a while now, and I've decided that it will
>>> likely be
>>> my mobile development language. I love Qt to death for desktop, but I've
>>> never been able to take to it's declarative approach. I know others
>>> swear by
>>> it, but it just never fit my brain waves for some reason.
>>>
>>>
>>> I guess I am one of those persons, who absolutely LOVE Qt's declarative
>>> language.
>>> I like QML so much, that I even started looking for QML -> HTML/CSS
>>> translators. While I really like QML,
>>> I absolutely hate HTML and CSS (never got used to its quirks). I mean
>>> there are some attempts like
>>> qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those
>>> yet.
>>>
>>>
>>> Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood >> >:
>>>
>>>> On 2/18/2019 7:40 AM, René Hansen wrote:
>>>> > I've not come across any myself, and have only built a few small
>>>> things with
>>>> > it a bit for now.
>>>> >
>>>> > Initial reactions was that it is *leagues* ahead of Qt with regards to
>>>> > developer experience. You'r
Re: [Interest] Fwd: vs. Flutter
Qt is free, too.
Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau
:
>I cannot get it copied in the email, but the code in the section get
>started has no "new" but I agree with you that it is not "declarative"
>
>The positive points about flutter is that it is free, and intellij
>(IDEA)
>is so great.
>However, it feels too young, and limited to mobile (some are saying
>that
>the desktop is coming, but nothing concrete yet)
>
>react native (via react xp) seems to be a better alternative for now.
>
>Best regards,
>Sylvain
>
>
>Le mar. 19 févr. 2019 à 19:43, Jason H a écrit :
>
>> It's still on the home page: https://flutter.io/ "Fast Development"
>> I operate on the "read at least the first page" premise. That
>whatever
>> they think is most important should be found there.
>>
>> But losing new doesn't really change my opinion of if it's
>declarative or
>> not.
>>
>> Thanks for the update/correction though.
>>
>>
>> *Sent:* Tuesday, February 19, 2019 at 1:34 PM
>> *From:* "Sylvain Pointeau"
>> *To:* "Qt Project"
>> *Subject:* [Interest] Fwd: vs. Flutter
>> the "new" is now removed in dart 2.0 so you example is outdated.
>>
>>
>> -- Message transféré -
>> De : Jason H
>> Date : mar. 19 févr. 2019 à 19:25
>> Objet : Re: [Interest] vs. Flutter
>> À : Bernhard B
>> CC :
>>
>> I'm in your offtopic camp.
>> Everything is going Declarative. I really hate that web devevlopment
>> requires the use of HTML/CSS/JS (that's just client side) and some
>> Framework of the Month. The JavaScript kiddies love inventing
>frameworks
>> for fame and profit rather than picking one and making it better.
>> Fragmentation is rampant. On top of that JS is slow to change, it
>just
>> becomes a runtime that your flavor-of-the-month framework compiles
>down to,
>> well until WebAssembly.
>>
>> Rene, I don't understand why you don't declare Flutter Declarative?
>From
>> the Flutter home page:
>> Widget build(BuildContext context) {
>> return new Scaffold (
>> appBar: new AppBar ( title: new Text (widget.title), ),
>> body: new Center (
>> child: new Text( "Button clicked" ...
>> ),
>> ),
>> }
>>
>> Good luck typing 'new' and 'return' a lot. At least QML manages that
>for
>> you. QML is the sleekest of all the declarative languages.
>>
>>
>> *Sent:* Tuesday, February 19, 2019 at 12:55 PM
>> *From:* "Bernhard B"
>> *To:* "Bob Hood"
>> *Cc:* "René Hansen" , "Jason H" ,
>> inter...@lists.qt-project.org
>>
>> *Subject:* Re: [Interest] vs. Flutter
>> > I've been studying it for a while now, and I've decided that it
>will
>> likely be
>> my mobile development language. I love Qt to death for desktop, but
>I've
>> never been able to take to it's declarative approach. I know others
>swear
>> by
>> it, but it just never fit my brain waves for some reason.
>>
>>
>> I guess I am one of those persons, who absolutely LOVE Qt's
>declarative
>> language.
>> I like QML so much, that I even started looking for QML -> HTML/CSS
>> translators. While I really like QML,
>> I absolutely hate HTML and CSS (never got used to its quirks). I mean
>> there are some attempts like
>> qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried
>those
>> yet.
>>
>>
>> Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood
>:
>>
>>> On 2/18/2019 7:40 AM, René Hansen wrote:
>>> > I've not come across any myself, and have only built a few small
>things
>>> with
>>> > it a bit for now.
>>> >
>>> > Initial reactions was that it is *leagues* ahead of Qt with
>regards to
>>> > developer experience. You're not locked to an IDE, like with
>QtCreator,
>>> and
>>> > the ui live updates across device, simulators, emulators etc. when
>you
>>> write
>>> > changes. No need to build and .apk and wait for a build+deploy.
>>> >
>>> > There's no JS involved. It's Dart all the way. It doesn't even
>ship
>>> with a
>>> > web runtime afaik.
>>>
>>> I've been studying it for a while now, and I've decided that it will
>>> likely be
Re: [Interest] Fwd: vs. Flutter
I cannot get it copied in the email, but the code in the section get
started has no "new" but I agree with you that it is not "declarative"
The positive points about flutter is that it is free, and intellij (IDEA)
is so great.
However, it feels too young, and limited to mobile (some are saying that
the desktop is coming, but nothing concrete yet)
react native (via react xp) seems to be a better alternative for now.
Best regards,
Sylvain
Le mar. 19 févr. 2019 à 19:43, Jason H a écrit :
> It's still on the home page: https://flutter.io/ "Fast Development"
> I operate on the "read at least the first page" premise. That whatever
> they think is most important should be found there.
>
> But losing new doesn't really change my opinion of if it's declarative or
> not.
>
> Thanks for the update/correction though.
>
>
> *Sent:* Tuesday, February 19, 2019 at 1:34 PM
> *From:* "Sylvain Pointeau"
> *To:* "Qt Project"
> *Subject:* [Interest] Fwd: vs. Flutter
> the "new" is now removed in dart 2.0 so you example is outdated.
>
>
> -- Message transféré -
> De : Jason H
> Date : mar. 19 févr. 2019 à 19:25
> Objet : Re: [Interest] vs. Flutter
> À : Bernhard B
> CC :
>
> I'm in your offtopic camp.
> Everything is going Declarative. I really hate that web devevlopment
> requires the use of HTML/CSS/JS (that's just client side) and some
> Framework of the Month. The JavaScript kiddies love inventing frameworks
> for fame and profit rather than picking one and making it better.
> Fragmentation is rampant. On top of that JS is slow to change, it just
> becomes a runtime that your flavor-of-the-month framework compiles down to,
> well until WebAssembly.
>
> Rene, I don't understand why you don't declare Flutter Declarative? From
> the Flutter home page:
> Widget build(BuildContext context) {
> return new Scaffold (
> appBar: new AppBar ( title: new Text (widget.title), ),
> body: new Center (
> child: new Text( "Button clicked" ...
> ),
> ),
> }
>
> Good luck typing 'new' and 'return' a lot. At least QML manages that for
> you. QML is the sleekest of all the declarative languages.
>
>
> *Sent:* Tuesday, February 19, 2019 at 12:55 PM
> *From:* "Bernhard B"
> *To:* "Bob Hood"
> *Cc:* "René Hansen" , "Jason H" ,
> inter...@lists.qt-project.org
>
> *Subject:* Re: [Interest] vs. Flutter
> > I've been studying it for a while now, and I've decided that it will
> likely be
> my mobile development language. I love Qt to death for desktop, but I've
> never been able to take to it's declarative approach. I know others swear
> by
> it, but it just never fit my brain waves for some reason.
>
>
> I guess I am one of those persons, who absolutely LOVE Qt's declarative
> language.
> I like QML so much, that I even started looking for QML -> HTML/CSS
> translators. While I really like QML,
> I absolutely hate HTML and CSS (never got used to its quirks). I mean
> there are some attempts like
> qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those
> yet.
>
>
> Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood :
>
>> On 2/18/2019 7:40 AM, René Hansen wrote:
>> > I've not come across any myself, and have only built a few small things
>> with
>> > it a bit for now.
>> >
>> > Initial reactions was that it is *leagues* ahead of Qt with regards to
>> > developer experience. You're not locked to an IDE, like with QtCreator,
>> and
>> > the ui live updates across device, simulators, emulators etc. when you
>> write
>> > changes. No need to build and .apk and wait for a build+deploy.
>> >
>> > There's no JS involved. It's Dart all the way. It doesn't even ship
>> with a
>> > web runtime afaik.
>>
>> I've been studying it for a while now, and I've decided that it will
>> likely be
>> my mobile development language. I love Qt to death for desktop, but I've
>> never been able to take to it's declarative approach. I know others
>> swear by
>> it, but it just never fit my brain waves for some reason.
>>
>> I saw somebody in this thread moan about it being yet another language to
>> learn. Putting aside the fact that a robust developer should know more
>> than
>> one, Dart is quite familiar to anybody who has used a modern scripting
>> language (e.g., Python).
>>
>> For me personally, Flutter's "feel" just fits mobile better in my mind
>> than Qt.
>>
>> ___
>> 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
> ___ 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
Re: [Interest] Fwd: vs. Flutter
It's still on the home page: https://flutter.io/ "Fast Development"
I operate on the "read at least the first page" premise. That whatever they think is most important should be found there.
But losing new doesn't really change my opinion of if it's declarative or not.
Thanks for the update/correction though.
Sent: Tuesday, February 19, 2019 at 1:34 PM
From: "Sylvain Pointeau"
To: "Qt Project"
Subject: [Interest] Fwd: vs. Flutter
the "new" is now removed in dart 2.0 so you example is outdated.
-- Message transféré -
De : Jason H <jh...@gmx.com>
Date : mar. 19 févr. 2019 à 19:25
Objet : Re: [Interest] vs. Flutter
À : Bernhard B <schluc...@gmail.com>
CC : <inter...@lists.qt-project.org>
I'm in your offtopic camp.
Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly.
Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page:
Widget build(BuildContext context) {
return new Scaffold (
appBar: new AppBar ( title: new Text (widget.title), ),
body: new Center (
child: new Text( "Button clicked" ...
),
),
}
Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages.
Sent: Tuesday, February 19, 2019 at 12:55 PM
From: "Bernhard B" <schluc...@gmail.com>
To: "Bob Hood" <bho...@comcast.net>
Cc: "René Hansen" <ren...@gmail.com>, "Jason H" <jh...@gmx.com>, inter...@lists.qt-project.org
Subject: Re: [Interest] vs. Flutter
> I've been studying it for a while now, and I've decided that it will likely be
my mobile development language. I love Qt to death for desktop, but I've
never been able to take to it's declarative approach. I know others swear by
it, but it just never fit my brain waves for some reason.
I guess I am one of those persons, who absolutely LOVE Qt's declarative language.
I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML,
I absolutely hate HTML and CSS (never got used to its quirks). I mean there are some attempts like
qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet.
Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood <bho...@comcast.net>:
On 2/18/2019 7:40 AM, René Hansen wrote:
> I've not come across any myself, and have only built a few small things with
> it a bit for now.
>
> Initial reactions was that it is *leagues* ahead of Qt with regards to
> developer experience. You're not locked to an IDE, like with QtCreator, and
> the ui live updates across device, simulators, emulators etc. when you write
> changes. No need to build and .apk and wait for a build+deploy.
>
> There's no JS involved. It's Dart all the way. It doesn't even ship with a
> web runtime afaik.
I've been studying it for a while now, and I've decided that it will likely be
my mobile development language. I love Qt to death for desktop, but I've
never been able to take to it's declarative approach. I know others swear by
it, but it just never fit my brain waves for some reason.
I saw somebody in this thread moan about it being yet another language to
learn. Putting aside the fact that a robust developer should know more than
one, Dart is quite familiar to anybody who has used a modern scripting
language (e.g., Python).
For me personally, Flutter's "feel" just fits mobile better in my mind than Qt.
___
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
___ 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
[Interest] Fwd: vs. Flutter
the "new" is now removed in dart 2.0 so you example is outdated.
-- Message transféré -
De : Jason H
Date : mar. 19 févr. 2019 à 19:25
Objet : Re: [Interest] vs. Flutter
À : Bernhard B
CC :
I'm in your offtopic camp.
Everything is going Declarative. I really hate that web devevlopment
requires the use of HTML/CSS/JS (that's just client side) and some
Framework of the Month. The JavaScript kiddies love inventing frameworks
for fame and profit rather than picking one and making it better.
Fragmentation is rampant. On top of that JS is slow to change, it just
becomes a runtime that your flavor-of-the-month framework compiles down to,
well until WebAssembly.
Rene, I don't understand why you don't declare Flutter Declarative? From
the Flutter home page:
Widget build(BuildContext context) {
return new Scaffold (
appBar: new AppBar ( title: new Text (widget.title), ),
body: new Center (
child: new Text( "Button clicked" ...
),
),
}
Good luck typing 'new' and 'return' a lot. At least QML manages that for
you. QML is the sleekest of all the declarative languages.
*Sent:* Tuesday, February 19, 2019 at 12:55 PM
*From:* "Bernhard B"
*To:* "Bob Hood"
*Cc:* "René Hansen" , "Jason H" ,
inter...@lists.qt-project.org
*Subject:* Re: [Interest] vs. Flutter
> I've been studying it for a while now, and I've decided that it will
likely be
my mobile development language. I love Qt to death for desktop, but I've
never been able to take to it's declarative approach. I know others swear
by
it, but it just never fit my brain waves for some reason.
I guess I am one of those persons, who absolutely LOVE Qt's declarative
language.
I like QML so much, that I even started looking for QML -> HTML/CSS
translators. While I really like QML,
I absolutely hate HTML and CSS (never got used to its quirks). I mean there
are some attempts like
qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet.
Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood :
> On 2/18/2019 7:40 AM, René Hansen wrote:
> > I've not come across any myself, and have only built a few small things
> with
> > it a bit for now.
> >
> > Initial reactions was that it is *leagues* ahead of Qt with regards to
> > developer experience. You're not locked to an IDE, like with QtCreator,
> and
> > the ui live updates across device, simulators, emulators etc. when you
> write
> > changes. No need to build and .apk and wait for a build+deploy.
> >
> > There's no JS involved. It's Dart all the way. It doesn't even ship with
> a
> > web runtime afaik.
>
> I've been studying it for a while now, and I've decided that it will
> likely be
> my mobile development language. I love Qt to death for desktop, but I've
> never been able to take to it's declarative approach. I know others swear
> by
> it, but it just never fit my brain waves for some reason.
>
> I saw somebody in this thread moan about it being yet another language to
> learn. Putting aside the fact that a robust developer should know more
> than
> one, Dart is quite familiar to anybody who has used a modern scripting
> language (e.g., Python).
>
> For me personally, Flutter's "feel" just fits mobile better in my mind
> than Qt.
>
> ___
> 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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
