Re: [Interest] vs. Flutter
1. Because my code is my organizations code and I don't have permission to share. (Commercial license) I do however file bugs, minimal examples and such, openly. 2. Because the code I write is done to satisfy a specific requirement, not Qt in general. Qt does have some of the best APIs, whereas mine is writtenwith one goal: fill the immediate requirement. As a result, it may not be ideally implemented and is not likely to work for others.. I don't know my ObjC or JNI code is proper, it just does what I need and doesn't crash. 3. For things like notifications: I cannot test all the notification providers (AWS, Firebase, etc) on allt he platforms. (i.e. Apple Push Notification data structure does not match any of the others) 3a. We'd need to agree to a standard because you should be able to swap providers and the app not need any changes. Whereas if "Qt" did it, they wouldn't need a committee. I could probably assist an effort by sharing experiences and non-application specific platform code but I would not want to lead/do it. For me, over the last 5 years I've bit the bullet and hacked the native platform code, so I generally have it. So for me, it's not the biggest deal. But for anyone new to Qt or new to iOS/Android, the moment they learn that Qt doesn't have API coverage for some feature that mobile phones have had for 10 years, I'm sure they get a sinking feeling and vertigo. I get a mini version of it every time I start a new app because the first few hours is spent just getting a skeleton app set up with native feature that I do have code for. It also doesn't help that Qt does not (and can't, apparently) use Swift, as that code is much more friendly and is becoming plentiful. In the mean time, my company's staffing is complicated by having to find people knowlegeable in ObjC, Java, C, C++, _javascript_ and threading that needle is increasingly difficult. ObjC, C, C++ are in decline. Maybe this is a way to sell Qt Developer licenses? But I honestly don't think so. So Qt's lack of mobile integration really hurts my organization. Unless Tukka et al commit to enhancing mobile, I will cease using Qt on Mobile. I think a lot of others will too. If Qt on Mobile is dead, I might as well take my chances with Google. At least people won't ask "What's Google" as they do with Qt. Sent: Tuesday, February 26, 2019 at 12:03 AM From: "Vlad Stelmahovsky" To: interest@qt-project.org Subject: Re: [Interest] vs. Flutter if you guys already did some code for mobiles, why dont just contribute back? On 2/20/19 3:32 AM, Jason H wrote: There's not anything I haven't done on mobile in Qt. The problem is everytime I start an app, I copy the 75% from the previous project and it's janky slap-dash of code. I've got to to this 3x for every app, every time. It's iOS, Android, and OSX. What I have works, it's not Troll quality. It is unforunately commercial code. I don't have hot-reload, but notificatons - push and local were working with Firebase on Android and iOS. Yeah, it's a couple weeks to develop all of that, but we're dozens of programmers re-inventing the wheel time and time again. This is not "code less create more". A few weeks of a couple developers and this would be a completely different situation instead person-years are being wasted. Sent: Tuesday, February 19, 2019 at 8:09 PM From: "Jérôme Godbout" To: "Lorne Sturtevant" , "interest@qt-project.org" Subject: Re: [Interest] vs. Flutter I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess. From: Interest On Behalf Of Lorne Sturtevant Sent: February 19, 2019 7:04 PM To: interest@qt-project.org Subject: Re: [Interest] vs. Flutter On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito _
Re: [Interest] vs. Flutter
Hi, For my mobile personal projects, I'm using Felgo (previous v-play), it implements the plugins for notification and other things. I love Qt, I'm using it from the version 0.5x (last century) but I want to be honest, I use Qt/Qml on mobile because I already know it (and it's a good tool) but if we taking a user that doesn't know Qt/Qml why should he use Qt if for complex things need JNI, OBject-C (no swift)? Maybe he will do first writing two native application. I think that everyone here wants the best for the Qt, so I think should good if the Qt people could consider seriously the Comments/complaints of the mobile developers or say the mobile is not important for us. The best publicity is happy customers. N. Il giorno mar 26 feb 2019 alle ore 06:07 Vlad Stelmahovsky < vladstelmahov...@gmail.com> ha scritto: > if you guys already did some code for mobiles, why dont just contribute > back? > On 2/20/19 3:32 AM, Jason H wrote: > > There's not anything I haven't done on mobile in Qt. The problem is > everytime I start an app, I copy the 75% from the previous project and it's > janky slap-dash of code. I've got to to this 3x for every app, every time. > It's iOS, Android, and OSX. What I have works, it's not Troll quality. It > is unforunately commercial code. I don't have hot-reload, but notificatons > - push and local were working with Firebase on Android and iOS. > > Yeah, it's a couple weeks to develop all of that, but we're dozens of > programmers re-inventing the wheel time and time again. This is not "code > less create more". A few weeks of a couple developers and this would be a > completely different situation instead person-years are being wasted. > > > *Sent:* Tuesday, February 19, 2019 at 8:09 PM > *From:* "Jérôme Godbout" > *To:* "Lorne Sturtevant" , > "interest@qt-project.org" > > *Subject:* Re: [Interest] vs. Flutter > > I did try a bit V-Play, but I did not like the fact I was stuck at a > particular Qt version (it was 5.6 when 5.10 was out, last time I checked). > Does the new Felgo allow to be used on other versoin and with up to date Qt > Creator? that was a real bummer to be stuck with old version. The project > seem to be fine aside from that problems. The price is a hard pill to > swallow, with Qt 3D I guess the V-Play was less future proof I guess. > > > > *From:* Interest > *On Behalf Of *Lorne Sturtevant > *Sent:* February 19, 2019 7:04 PM > *To:* interest@qt-project.org > *Subject:* Re: [Interest] vs. Flutter > > > > On 2019-02-19 3:22 p.m., Jason H wrote: > > Was just reading the blog and it mentions live reloading: > https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ > > > > This Neptune3 thing, is that something we can use on the phones? > > > > I've been following the discussion and it looks like a lot of features of > flutter, such as the live reloading, push notification, etc, already exists > in felgo (use to be vplay). I used vplay for awhile, but it got too > expensive so I just redid what I was using from their work myself. Only > took a couple of weeks. My main point is that Qt can do all of this stuff > because the felgo people already did. It just has to be done by Qt and put > into the core. > > > -- > > Lorne Sturtevant > > Sum Ergo Cogito > > ___ Interest mailing list > Interest@qt-project.org https://lists.qt-project.org/listinfo/interest > > ___ > Interest mailing > listInterest@qt-project.orghttps://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] vs. Flutter
if you guys already did some code for mobiles, why dont just contribute back? On 2/20/19 3:32 AM, Jason H wrote: There's not anything I haven't done on mobile in Qt. The problem is everytime I start an app, I copy the 75% from the previous project and it's janky slap-dash of code. I've got to to this 3x for every app, every time. It's iOS, Android, and OSX. What I have works, it's not Troll quality. It is unforunately commercial code. I don't have hot-reload, but notificatons - push and local were working with Firebase on Android and iOS. Yeah, it's a couple weeks to develop all of that, but we're dozens of programmers re-inventing the wheel time and time again. This is not "code less create more". A few weeks of a couple developers and this would be a completely different situation instead person-years are being wasted. *Sent:* Tuesday, February 19, 2019 at 8:09 PM *From:* "Jérôme Godbout" *To:* "Lorne Sturtevant" , "interest@qt-project.org" *Subject:* Re: [Interest] vs. Flutter I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess. *From:*Interest *On Behalf Of *Lorne Sturtevant *Sent:* February 19, 2019 7:04 PM *To:* interest@qt-project.org *Subject:* Re: [Interest] vs. Flutter On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito ___ 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] vs. Flutter
There's not anything I haven't done on mobile in Qt. The problem is everytime I start an app, I copy the 75% from the previous project and it's janky slap-dash of code. I've got to to this 3x for every app, every time. It's iOS, Android, and OSX. What I have works, it's not Troll quality. It is unforunately commercial code. I don't have hot-reload, but notificatons - push and local were working with Firebase on Android and iOS. Yeah, it's a couple weeks to develop all of that, but we're dozens of programmers re-inventing the wheel time and time again. This is not "code less create more". A few weeks of a couple developers and this would be a completely different situation instead person-years are being wasted. Sent: Tuesday, February 19, 2019 at 8:09 PM From: "Jérôme Godbout" To: "Lorne Sturtevant" , "interest@qt-project.org" Subject: Re: [Interest] vs. Flutter I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess. From: Interest On Behalf Of Lorne Sturtevant Sent: February 19, 2019 7:04 PM To: interest@qt-project.org Subject: Re: [Interest] vs. Flutter On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito ___ 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] vs. Flutter
I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess. From: Interest On Behalf Of Lorne Sturtevant Sent: February 19, 2019 7:04 PM To: interest@qt-project.org Subject: Re: [Interest] vs. Flutter On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On Wed, 20 Feb 2019 at 00:33, Jason H wrote: > Also, FWIW, I don't know why PySide didn't take up Riverbank's PyQt. So now > we have Mobile and Python fragmentation in Qt. They did try, but couldn't reach an agreement with Riverbank: https://wiki.qt.io/PySide_FAQ (see "What About PyQt?") PyQt is Commercial/GPL only. Nokia (the then-owners of Qt) wanted LGPL. Regards, Sze-Howe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? Sent: Monday, February 18, 2019 at 3:40 PM From: "René Hansen" To: "Jason H" Cc: inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter 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. Achitecturally it's similar to Qt, in that they've build a custom renderer on top of Skia, so the whole scene is basically just OpenGL, which makes it really fast. Component wise, their UI library offers bother Cupertino and Material design out of the box, and from initial impressions, looks to be closer to the original design guidelines than Qt Quick Controls for. e.g. Material. I haven't tried it out myself yet, but you should be able to reach into native world by using platform channels: https://flutter.io/docs/development/platform-integration/platform-channels It's seems like it's quite a ways worse than with Qt though, so there's at least that. /René On Mon, 18 Feb 2019 at 14:58 Jason H <jh...@gmx.com> wrote: Are there any good Qt vs Google Flutter comparisons? I took a brief look, it looked like a declarative JS framework. Usually the difference with between Qt and the competition is Qt abstracts there platform libraries (i.e. Gstreamer vs avfoundation vs directshow) ___ 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] vs. Flutter
So I think that after all this chatter we have one really solid concrete finding: Findings #1: Qt is based on proven, stable technologies, whereas Flutter is based on Dart, a nacent technology with a very small past and a non-transparent future.* Furthermore, Dart does not seem to be any more adept at the needs of Flutter than any other language. I don't know if the "kids these days" will really be into that, as they are very into learning the "latest and greatest" (aka fads). * "non-transparent future" - while no one knows the future at least C++ has the 3 year release cycle. Qt's future is murky though without a dedicated roadmap. Sent: Tuesday, February 19, 2019 at 10:14 PM From: "Fabio Giovagnini" To: fro...@tungware.se Cc: Qt-interest Subject: Re: [Interest] vs. Flutter My two cents. The main topic is: a new language really has to give an answer to a real need. In my humble opinion when we talk about programming language, we cannot think to push artificial needs. The community of developers is not a commumitiy of fashion guys. They are professionals working to make money and innovate the market. The tools are not ideological matter but real tools to work, produce and make value. So, chancing for changing, only applying the logic "newer is better" is not always a winning choice. Best regards. Fabio Il giorno mar 19 feb 2019 21:58 Henry Skoglund <fro...@tungware.se> ha scritto: Hi, totally agree C/C++ will outlive many of these new languages. It's also most likely _javascript_ will wane off sooner rather than later due to WebAssembly steadily improving. Been working/programming for 43 years now, while I fondly remember Pascal on CP/M from my youth (before C++ was invented), once I switched to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home". Also you could say that good and stable ecosystems for a language takes decades to arrive, at least one generation of programmers has to come and go I think. So the peak of C++ will be in the future :-) Rgrds Henry On 2019-02-19 21:13, Christoph Feck wrote: > On 02/19/19 20:47, Jason H wrote: >> What I've learned is that it's better to stand on the shoulders of >> giants than to rewrite the universe from scratch. I dream of a say >> where we can code things and everyone else regardless of platform can >> run it. I thought this was going to be .Net CLR, or Java VM, but >> corporate ownership initiatives derailed them (Much like the "You >> will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ >> runs all more platforms/processors. Linux has come a long way in terms >> of bringing all CPUs a usable software ecosystem. And this though >> rather obtuse is one reason to pick Qt - that it'll support any system >> that can run a C++ compiler. You don't technically need to use QML, >> you can keep going with C++. > > Once upon a time a mother of two curious boys called me, asking me to > teach them programming. They have no clue what language to start with, > so I suggested C as a base, to later learn Python, C++, Java (or C#). > Then some "smart" student told one of the kids "_javascript_ is da future > of da Internetz". I stopped teaching them after it was suggested to > stop the C course and swap it for a _javascript_ course. > > C/C++ will be relevant in the future. All other languages will come and > go (no pun intended). > > Whether Qt will be relevant in the future lies in the hands of its > developers. Don't ruin it. > > Christoph Feck ___ 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] vs. Flutter
In 1992 it really, really was. The real issue nowadays is they only have one event loop forcing generators/async code. Though WebWorkers are a thing. Sent: Tuesday, February 19, 2019 at 10:03 PM From: "Sylvain Pointeau" To: "Christoph Feck" Cc: inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter I am personally not convinced yet about having a _javascript_ VM. It seems to be a bottleneck. However I see the advantages it brings, but was it really necessary? Le mar. 19 févr. 2019 à 21:15, Christoph Feck <cf...@kde.org> a écrit : On 02/19/19 20:47, Jason H wrote: > What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Once upon a time a mother of two curious boys called me, asking me to teach them programming. They have no clue what language to start with, so I suggested C as a base, to later learn Python, C++, Java (or C#). Then some "smart" student told one of the kids "_javascript_ is da future of da Internetz". I stopped teaching them after it was suggested to stop the C course and swap it for a _javascript_ course. C/C++ will be relevant in the future. All other languages will come and go (no pun intended). Whether Qt will be relevant in the future lies in the hands of its developers. Don't ruin it. Christoph Feck ___ 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] vs. Flutter
I probably would have gone with Python, and avoid pointers, as many languages
to their best to obfuscate them. But your C was not a bad decision. It is
lingua franca. :-)
Just remind them that JS was invented in 10 days back in 1992, and standardized
by a committee that had no business standardizing it. That said, with
everything targeting JS, it's not a bad decision either.
I'm relatively [adjective] about the new C++ versions. On one hand C++ looks
strange. The code to map/filter/transform looks nothing like I'd expect
(transform):
Actual:
std::vector x = {1, 2, 3, 4, 5};
std::vector y;
std::transform(x.begin(), x.end(), std::back_inserter(y), [](int elem){ return
elem * elem; });
Expected:
auto y = std::transform(std::vector {1, 2, 3, 4, 5}, [int elem] { return
elem*elem });
But the new initializer syntax is a joy.
SFINAE, etc. It creates pretty unreadable code. It takes me several minutes to
parse a line of modern C++, which violates several software development
principles in that it should be easy to understand, optimized for reading,
OTHER Developers, DRY, DR's 10 times harder statement. I've learned that to
grok C++, you must first realize that you're not writing a program that does
something, instead you're telling the compiler how to build the program. "Doing
what you want" is just a "side effect".
I don't know how long C++ can exist with that mentality. The compiler should
figure out what I mean. Const should be automatically applied where it can
based on code paths. It's something I do, it's easy to determine, and having it
auto applied would be just fine. Or maybe have a linter tell you/upgrade it to
const.
Qt is attractive because I "code less and create more". I rely on Qt to
translate the C++ committee's/stdlib output into something usable by
developers, not language nerds. (Reminder there's more languages than C++, I've
got to learn Dart now, apparently)
But the new initializer syntax is a joy, at least.
> Sent: Tuesday, February 19, 2019 at 9:13 PM
> From: "Christoph Feck"
> To: inter...@lists.qt-project.org
> Subject: Re: [Interest] vs. Flutter
>
> On 02/19/19 20:47, Jason H wrote:
> > What I've learned is that it's better to stand on the shoulders of giants
> > than to rewrite the universe from scratch. I dream of a say where we can
> > code things and everyone else regardless of platform can run it. I thought
> > this was going to be .Net CLR, or Java VM, but corporate ownership
> > initiatives derailed them (Much like the "You will" ATT ads of the 90s - we
> > got it, but not from ATT). But C/C++ runs all more platforms/processors.
> > Linux has come a long way in terms of bringing all CPUs a usable software
> > ecosystem. And this though rather obtuse is one reason to pick Qt - that
> > it'll support any system that can run a C++ compiler. You don't technically
> > need to use QML, you can keep going with C++.
>
> Once upon a time a mother of two curious boys called me, asking me to
> teach them programming. They have no clue what language to start with,
> so I suggested C as a base, to later learn Python, C++, Java (or C#).
> Then some "smart" student told one of the kids "JavaScript is da future
> of da Internetz". I stopped teaching them after it was suggested to
> stop the C course and swap it for a JavaScript course.
>
> C/C++ will be relevant in the future. All other languages will come and
> go (no pun intended).
>
> Whether Qt will be relevant in the future lies in the hands of its
> developers. Don't ruin it.
>
> Christoph Feck
>
> ___
> 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] vs. Flutter
My two cents. The main topic is: a new language really has to give an answer to a real need. In my humble opinion when we talk about programming language, we cannot think to push artificial needs. The community of developers is not a commumitiy of fashion guys. They are professionals working to make money and innovate the market. The tools are not ideological matter but real tools to work, produce and make value. So, chancing for changing, only applying the logic "newer is better" is not always a winning choice. Best regards. Fabio Il giorno mar 19 feb 2019 21:58 Henry Skoglund ha scritto: > Hi, totally agree C/C++ will outlive many of these new languages. > It's also most likely Javascript will wane off sooner rather than later > due to WebAssembly steadily improving. > > Been working/programming for 43 years now, while I fondly remember > Pascal on CP/M from my youth (before C++ was invented), once I switched > to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home". > > Also you could say that good and stable ecosystems for a language takes > decades to arrive, at least one generation of programmers has to come > and go I think. So the peak of C++ will be in the future :-) > > Rgrds Henry > > On 2019-02-19 21:13, Christoph Feck wrote: > > On 02/19/19 20:47, Jason H wrote: > >> What I've learned is that it's better to stand on the shoulders of > >> giants than to rewrite the universe from scratch. I dream of a say > >> where we can code things and everyone else regardless of platform can > >> run it. I thought this was going to be .Net CLR, or Java VM, but > >> corporate ownership initiatives derailed them (Much like the "You > >> will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ > >> runs all more platforms/processors. Linux has come a long way in terms > >> of bringing all CPUs a usable software ecosystem. And this though > >> rather obtuse is one reason to pick Qt - that it'll support any system > >> that can run a C++ compiler. You don't technically need to use QML, > >> you can keep going with C++. > > > > Once upon a time a mother of two curious boys called me, asking me to > > teach them programming. They have no clue what language to start with, > > so I suggested C as a base, to later learn Python, C++, Java (or C#). > > Then some "smart" student told one of the kids "JavaScript is da future > > of da Internetz". I stopped teaching them after it was suggested to > > stop the C course and swap it for a JavaScript course. > > > > C/C++ will be relevant in the future. All other languages will come and > > go (no pun intended). > > > > Whether Qt will be relevant in the future lies in the hands of its > > developers. Don't ruin it. > > > > Christoph Feck > > ___ > 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] vs. Flutter
I am personally not convinced yet about having a javascript VM. It seems to be a bottleneck. However I see the advantages it brings, but was it really necessary? Le mar. 19 févr. 2019 à 21:15, Christoph Feck a écrit : > On 02/19/19 20:47, Jason H wrote: > > What I've learned is that it's better to stand on the shoulders of > giants than to rewrite the universe from scratch. I dream of a say where we > can code things and everyone else regardless of platform can run it. I > thought this was going to be .Net CLR, or Java VM, but corporate ownership > initiatives derailed them (Much like the "You will" ATT ads of the 90s - we > got it, but not from ATT). But C/C++ runs all more platforms/processors. > Linux has come a long way in terms of bringing all CPUs a usable software > ecosystem. And this though rather obtuse is one reason to pick Qt - that > it'll support any system that can run a C++ compiler. You don't technically > need to use QML, you can keep going with C++. > > Once upon a time a mother of two curious boys called me, asking me to > teach them programming. They have no clue what language to start with, > so I suggested C as a base, to later learn Python, C++, Java (or C#). > Then some "smart" student told one of the kids "JavaScript is da future > of da Internetz". I stopped teaching them after it was suggested to > stop the C course and swap it for a JavaScript course. > > C/C++ will be relevant in the future. All other languages will come and > go (no pun intended). > > Whether Qt will be relevant in the future lies in the hands of its > developers. Don't ruin it. > > Christoph Feck > > ___ > 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] vs. Flutter
Hi, totally agree C/C++ will outlive many of these new languages. It's also most likely Javascript will wane off sooner rather than later due to WebAssembly steadily improving. Been working/programming for 43 years now, while I fondly remember Pascal on CP/M from my youth (before C++ was invented), once I switched to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home". Also you could say that good and stable ecosystems for a language takes decades to arrive, at least one generation of programmers has to come and go I think. So the peak of C++ will be in the future :-) Rgrds Henry On 2019-02-19 21:13, Christoph Feck wrote: On 02/19/19 20:47, Jason H wrote: What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Once upon a time a mother of two curious boys called me, asking me to teach them programming. They have no clue what language to start with, so I suggested C as a base, to later learn Python, C++, Java (or C#). Then some "smart" student told one of the kids "JavaScript is da future of da Internetz". I stopped teaching them after it was suggested to stop the C course and swap it for a JavaScript course. C/C++ will be relevant in the future. All other languages will come and go (no pun intended). Whether Qt will be relevant in the future lies in the hands of its developers. Don't ruin it. Christoph Feck ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On 02/19/19 20:47, Jason H wrote: What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Once upon a time a mother of two curious boys called me, asking me to teach them programming. They have no clue what language to start with, so I suggested C as a base, to later learn Python, C++, Java (or C#). Then some "smart" student told one of the kids "JavaScript is da future of da Internetz". I stopped teaching them after it was suggested to stop the C course and swap it for a JavaScript course. C/C++ will be relevant in the future. All other languages will come and go (no pun intended). Whether Qt will be relevant in the future lies in the hands of its developers. Don't ruin it. Christoph Feck ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
https://hub.packtpub.com/is-dart-programming-dead-already/ claims Dart is not Dead, just Mostly Dead and that Flutter will save the day... I don't want to learn yet another language to learn a toolkit. I know plenty already. C/C++, JS, Python, C#, Java, Obj-C, Perl, BASH, (Visual)BASIC, Lua, Ruby, Scala. (I'm not including SQL) I previously wrote that everything compiles to JS, and so does Dart, apparently LOL. Now everything is better than Perl, but yet another language? Given a list of those 12 languages they rejected them all and and declared they needed to make another one? It's got a NIH stench about it. What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Oh, looks like they are announcing relaunch for Dart, as of a year ago: https://sdtimes.com/webdev/google-announces-reboot-programming-language-dart/ Meanwhile they develop Tensorflow in Python? Android in Java and now Kotlin Where's Go[lang] And unit tests for it all? It's just too easy to invent a language or framework, and too hard to change an existing one. Dunning Kruger effect? Every time you create a new language or framework, you divide humanity into those who can benefit from your work and those who can't. Those who are using your platform or language against those who aren't. I'm not against experimenting, but asking other to devs to use your unique stuff should be a much bigger ask. Right now we've got Kotlin infecting Android/Java for a slightly different syntax than the languages above, no material gain. Meanwhile your veteran languages are getting infected with async stuff. Qt's Mobile problems are just a backlog of ancient mobile platform concepts not yet delivered. After that backlog is resolved the maintenance is rather light, as mobile devices aren't still moving. Sure FaceID is new, but it works the same as TouchId. But these non-delivered concepts are continual pain points for its users. It's very easy for these new toolkits to wrap platform APIs, but Qt remains the only one to successfully* abstract them. * platform parity issues persist. > Sent: Tuesday, February 19, 2019 at 6:42 PM > From: "Bob Hood" > To: "René Hansen" , "Jason H" > Cc: inter...@lists.qt-project.org > Subject: Re: [Interest] vs. Flutter > > 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
Re: [Interest] vs. Flutter
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 <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
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
Re: [Interest] vs. Flutter
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
Re: [Interest] vs. Flutter
> I've never said this before, but I think Qt's days are numbered unless they get their ecosystem in order. With Google entering the x-platform marketplace about the hopes Qt has is to somehow deliver better than Google, or hope that Flutter is fleeting Not sure...Qt definitely has it's strengths. Google on the other hand has the reputation that they abandon stuff they don't need anymore, or change the API in a way that all community driven libraries become useless (looking at you, tensorflow). But what I am definitely missing, is a clear Qt roadmap. What are Qt's focusing areas for 2019 and beyond? Will it be mobile, embedded, IoT, desktop, 3D, ...? Am Di., 19. Feb. 2019, 17:33 hat Jason H geschrieben: > Yes the V-Play peeps seem to have this nut cracked as well as other mobile > efforts. But here's the rub: it should just be part of Qt and I shouldn't > need to go two places. If V-Play (Felgo) can make a business out of these > efforts, why isn't it the same for Qt proper? I keep rolling my eyes at all > the 3D stuff going into Qt (which admittedly is *very cool*, but not what I > need) but what I *need* is mobile to "just work". I don't even get why the > Qt stuff is done, just use 3D to generate your 2D IVI animations and UI > elements. > > If all the effort put into 3D was put into mobile, we'd have mobile done a > few times over by now. > > I think Qt should to acquire Felgo to be a 1-stop shop. Also, FWIW, I > don't know why PySide didn't take up Riverbank's PyQt. So now we have > Mobile and Python fragmentation in Qt. > > I've never said this before, but I think Qt's days are numbered unless > they get their ecosystem in order. With Google entering the x-platform > marketplace about the hopes Qt has is to somehow deliver better than > Google, or hope that Flutter is fleeting. Google has been a little ADHD > with projects, so... maybe? > > > > > Sent: Tuesday, February 19, 2019 at 10:50 AM > > From: "Jereme Givens- Lamothe" > > To: "interest@qt-project.org" > > Cc: "Jason H" > > Subject: Re: [Interest] vs. Flutter > > > > Does something like the (recently rebranded) Felgo address any of your > concerns about mobile development w/ Qt? They used to call the product > "V-Play", but wanted to market it for use in regular apps (non-games) as > well. I haven't used it myself, but they seem to handle QML live-reload and > notifications. > > > > https://felgo.com/qml-live-code-reload > > > https://felgo.com/doc/apps-get-started-for-ios-developers/#how-do-i-set-up-push-notifications > > > > > > From: Interest on behalf of Jason H < > jh...@gmx.com> > > Sent: Tuesday, February 19, 2019 10:25 AM > > To: "René Hansen" > > Cc: inter...@lists.qt-project.org > > Subject: Re: [Interest] vs. Flutter > > > > Many thanks for all those who replied. > > > > > 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. > > > > What if there was a way to stand up a QmlEngine, host it on a phone, > then start the app and then ship the QML over to it, then when a new > version is ready, reset the engine and reload? This doesn't seem like > anything that would be really hard to add to Qt/QtCreator? > > > > > There's no JS involved. It's Dart all the way. It doesn't even ship > with a web runtime afaik. > > > > > > Achitecturally it's similar to Qt, in that they've build a custom > renderer on top of Skia, so the whole scene is basically just OpenGL, which > makes it really fast. > > > > > > Component wise, their UI library offers bother Cupertino and Material > design out of the box, and from initial impressions, looks to be closer to > the original design guidelines than Qt Quick Controls for. e.g. Material. > > > > This doesn't sound like anything we can't have either? > > > > > I haven't tried it out myself yet, but you should be able to reach > into native world by using platform channels: > > > > > > > https://flutter.io/docs/development/platform-integration/platform-channels > > > > > > It's seems like it's quite a ways worse than with Qt though, so > there's at least that. > > > > Well, Qt on Mobile is relatively abysmal. There is a much higher lack of > parity than anywhere else. Th
Re: [Interest] vs. Flutter
Yes the V-Play peeps seem to have this nut cracked as well as other mobile efforts. But here's the rub: it should just be part of Qt and I shouldn't need to go two places. If V-Play (Felgo) can make a business out of these efforts, why isn't it the same for Qt proper? I keep rolling my eyes at all the 3D stuff going into Qt (which admittedly is *very cool*, but not what I need) but what I *need* is mobile to "just work". I don't even get why the Qt stuff is done, just use 3D to generate your 2D IVI animations and UI elements. If all the effort put into 3D was put into mobile, we'd have mobile done a few times over by now. I think Qt should to acquire Felgo to be a 1-stop shop. Also, FWIW, I don't know why PySide didn't take up Riverbank's PyQt. So now we have Mobile and Python fragmentation in Qt. I've never said this before, but I think Qt's days are numbered unless they get their ecosystem in order. With Google entering the x-platform marketplace about the hopes Qt has is to somehow deliver better than Google, or hope that Flutter is fleeting. Google has been a little ADHD with projects, so... maybe? > Sent: Tuesday, February 19, 2019 at 10:50 AM > From: "Jereme Givens- Lamothe" > To: "interest@qt-project.org" > Cc: "Jason H" > Subject: Re: [Interest] vs. Flutter > > Does something like the (recently rebranded) Felgo address any of your > concerns about mobile development w/ Qt? They used to call the product > "V-Play", but wanted to market it for use in regular apps (non-games) as > well. I haven't used it myself, but they seem to handle QML live-reload and > notifications. > > https://felgo.com/qml-live-code-reload > https://felgo.com/doc/apps-get-started-for-ios-developers/#how-do-i-set-up-push-notifications > > > From: Interest on behalf of Jason H > > Sent: Tuesday, February 19, 2019 10:25 AM > To: "René Hansen" > Cc: inter...@lists.qt-project.org > Subject: Re: [Interest] vs. Flutter > > Many thanks for all those who replied. > > > 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. > > What if there was a way to stand up a QmlEngine, host it on a phone, then > start the app and then ship the QML over to it, then when a new version is > ready, reset the engine and reload? This doesn't seem like anything that > would be really hard to add to Qt/QtCreator? > > > There's no JS involved. It's Dart all the way. It doesn't even ship with a > > web runtime afaik. > > > > Achitecturally it's similar to Qt, in that they've build a custom renderer > > on top of Skia, so the whole scene is basically just OpenGL, which makes it > > really fast. > > > > Component wise, their UI library offers bother Cupertino and Material > > design out of the box, and from initial impressions, looks to be closer to > > the original design guidelines than Qt Quick Controls for. e.g. Material. > > This doesn't sound like anything we can't have either? > > > I haven't tried it out myself yet, but you should be able to reach into > > native world by using platform channels: > > > > https://flutter.io/docs/development/platform-integration/platform-channels > > > > It's seems like it's quite a ways worse than with Qt though, so there's at > > least that. > > Well, Qt on Mobile is relatively abysmal. There is a much higher lack of > parity than anywhere else. The recent Developer Survey gave me some hope > though: 10% embedded 20% mobile. This was suggested to being some much needed > love to Mobile. I will say that my commercial support seems to trigger the > fixing of those issues pretty quickly. So it's not being ignored. One of my > chief frustrations with the Qt Project as a whole is lack of a roadmap. > > Things that need attention in 2015 (yeah long overdue) > * Notifications API (Desktop, Mobile) > * Multimedia platform parity with each other and desktop. > * Device support APIs (display brightness, volume, etc) > > All those things still need attention in 2019. > > I don't know how flutter runs on Windows or embedded hardware though. Maybe > all you need is ASOP? > > ___ > 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] vs. Flutter
Does something like the (recently rebranded) Felgo address any of your concerns about mobile development w/ Qt? They used to call the product "V-Play", but wanted to market it for use in regular apps (non-games) as well. I haven't used it myself, but they seem to handle QML live-reload and notifications. https://felgo.com/qml-live-code-reload https://felgo.com/doc/apps-get-started-for-ios-developers/#how-do-i-set-up-push-notifications From: Interest on behalf of Jason H Sent: Tuesday, February 19, 2019 10:25 AM To: "René Hansen" Cc: inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter Many thanks for all those who replied. > 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. What if there was a way to stand up a QmlEngine, host it on a phone, then start the app and then ship the QML over to it, then when a new version is ready, reset the engine and reload? This doesn't seem like anything that would be really hard to add to Qt/QtCreator? > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. > > Achitecturally it's similar to Qt, in that they've build a custom renderer on > top of Skia, so the whole scene is basically just OpenGL, which makes it > really fast. > > Component wise, their UI library offers bother Cupertino and Material design > out of the box, and from initial impressions, looks to be closer to the > original design guidelines than Qt Quick Controls for. e.g. Material. This doesn't sound like anything we can't have either? > I haven't tried it out myself yet, but you should be able to reach into > native world by using platform channels: > > https://flutter.io/docs/development/platform-integration/platform-channels > > It's seems like it's quite a ways worse than with Qt though, so there's at > least that. Well, Qt on Mobile is relatively abysmal. There is a much higher lack of parity than anywhere else. The recent Developer Survey gave me some hope though: 10% embedded 20% mobile. This was suggested to being some much needed love to Mobile. I will say that my commercial support seems to trigger the fixing of those issues pretty quickly. So it's not being ignored. One of my chief frustrations with the Qt Project as a whole is lack of a roadmap. Things that need attention in 2015 (yeah long overdue) * Notifications API (Desktop, Mobile) * Multimedia platform parity with each other and desktop. * Device support APIs (display brightness, volume, etc) All those things still need attention in 2019. I don't know how flutter runs on Windows or embedded hardware though. Maybe all you need is ASOP? ___ 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] vs. Flutter
Many thanks for all those who replied. > 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. What if there was a way to stand up a QmlEngine, host it on a phone, then start the app and then ship the QML over to it, then when a new version is ready, reset the engine and reload? This doesn't seem like anything that would be really hard to add to Qt/QtCreator? > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. > > Achitecturally it's similar to Qt, in that they've build a custom renderer on > top of Skia, so the whole scene is basically just OpenGL, which makes it > really fast. > > Component wise, their UI library offers bother Cupertino and Material design > out of the box, and from initial impressions, looks to be closer to the > original design guidelines than Qt Quick Controls for. e.g. Material. This doesn't sound like anything we can't have either? > I haven't tried it out myself yet, but you should be able to reach into > native world by using platform channels: > > https://flutter.io/docs/development/platform-integration/platform-channels > > It's seems like it's quite a ways worse than with Qt though, so there's at > least that. Well, Qt on Mobile is relatively abysmal. There is a much higher lack of parity than anywhere else. The recent Developer Survey gave me some hope though: 10% embedded 20% mobile. This was suggested to being some much needed love to Mobile. I will say that my commercial support seems to trigger the fixing of those issues pretty quickly. So it's not being ignored. One of my chief frustrations with the Qt Project as a whole is lack of a roadmap. Things that need attention in 2015 (yeah long overdue) * Notifications API (Desktop, Mobile) * Multimedia platform parity with each other and desktop. * Device support APIs (display brightness, volume, etc) All those things still need attention in 2019. I don't know how flutter runs on Windows or embedded hardware though. Maybe all you need is ASOP? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
19.02.2019, 15:27, "Vlad Stelmahovsky" : > QtMultimedia cant be less power than GStreamer, because QtMultimedia on linux > uses gstreamer as backend :) It's less powerful because its API provides lowest common denominator of all media backends > However I'd like to see there something like custom pipeline provider to > Gstreamer it would be really useful for different usecases > > br, > Vlad > > On Mon, Feb 18, 2019 at 9:39 PM Christian Gagneraud wrote: >> On Tue, 19 Feb 2019 at 02:57, Jason H wrote: >>> >>> Are there any good Qt vs Google Flutter comparisons? >>> I took a brief look, it looked like a declarative JS framework. Usually the >>> difference with between Qt and the competition is Qt abstracts there >>> platform libraries (i.e. Gstreamer vs avfoundation vs directshow) >> >> OT: This is not always a good thing. QtMultimedia is less powerful >> than Gstreamer for example. So if you target embedded Linux, you might >> prefer to use gstreamer directly instead of using QtMultimedia. >> >> Chris >> >>> ___ >>> 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 > > -- > Best regards, > Vlad > , > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On Tue, 19 Feb 2019 at 06:58 Shawn Rutledge wrote: > On Feb 18, 2019, at 17:18, René Hansen wrote: > > On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge wrote: > >> >> > On 18 Feb 2019, at 15:40, René Hansen wrote: >> > >> > Achitecturally it's similar to Qt, in that they've build a custom >> renderer on top of Skia, so the whole scene is basically just OpenGL, which >> makes it really fast. >> > >> > Component wise, their UI library offers bother Cupertino and Material >> design out of the box, and from initial impressions, looks to be closer to >> the original design guidelines than Qt Quick Controls for. e.g. Material. >> >> In what way? >> > > This might just be my own personal experience, but I've run into weird and > "finicky" behaviours with Qt Quick Controls, quite a number of times and so > far, from the admittedly smaller sample size, I've not seen the same issues > with widgets in Flutter. > > > That still sounds vague. I hope you will write up bugs with concrete > examples of what’s weird. > I've kind of given up reporting bugs, unless they're really big. Again, this is just my personal experience, but I've long felt that minor bug reports are just left to rot in the tracker, so why even bother. Here's one I did report though; about TextInput: https://bugreports.qt.io/browse/QTBUG-69625. That's an example of what I mean by weird. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
QtMultimedia cant be less power than GStreamer, because QtMultimedia on linux uses gstreamer as backend :) However I'd like to see there something like custom pipeline provider to Gstreamer it would be really useful for different usecases br, Vlad On Mon, Feb 18, 2019 at 9:39 PM Christian Gagneraud wrote: > On Tue, 19 Feb 2019 at 02:57, Jason H wrote: > > > > Are there any good Qt vs Google Flutter comparisons? > > I took a brief look, it looked like a declarative JS framework. Usually > the difference with between Qt and the competition is Qt abstracts there > platform libraries (i.e. Gstreamer vs avfoundation vs directshow) > > OT: This is not always a good thing. QtMultimedia is less powerful > than Gstreamer for example. So if you target embedded Linux, you might > prefer to use gstreamer directly instead of using QtMultimedia. > > Chris > > > ___ > > 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 > -- Best regards, Vlad ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On Feb 18, 2019, at 17:18, René Hansen mailto:ren...@gmail.com>> wrote: On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge mailto:shawn.rutle...@qt.io>> wrote: > On 18 Feb 2019, at 15:40, René Hansen > mailto:ren...@gmail.com>> wrote: > Achitecturally it's similar to Qt, in that they've build a custom renderer on > top of Skia, so the whole scene is basically just OpenGL, which makes it > really fast. > > Component wise, their UI library offers bother Cupertino and Material design > out of the box, and from initial impressions, looks to be closer to the > original design guidelines than Qt Quick Controls for. e.g. Material. In what way? This might just be my own personal experience, but I've run into weird and "finicky" behaviours with Qt Quick Controls, quite a number of times and so far, from the admittedly smaller sample size, I've not seen the same issues with widgets in Flutter. That still sounds vague. I hope you will write up bugs with concrete examples of what’s weird. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
I asked a question about this during the Qt Virtual Tech summit. It seems that The Qt Company acknowledges that Qt is being used for mobile more and more. I asked to Lars Knoll If there were plans to invest more in mobile to bring some native functionality, and he said that there are plans but it's a matter of time management. So, I wouldn't hold my breath. They seem to have a higher paying customer base in automative and embedded so they seem to get higher priorities. But the fact that C++/Qt is pretty easy to interface with the native libraries is comforting enough. I've developed various apps, and I was able to implement the native functionality using JNI and Objective-C fairly easily. Regards, Furkan Üzümcü On Feb 18, 2019, 12:11 -0500, Bernhard B , wrote: > Just out of curiosity: Does the recent flutter 1.0 release have an impact on > Qt's strategic orientation? Is flutter seen as a direct competitor to Qt? > Will there be more/less focus on Qt mobile? > > I recently had to re-evaluate whether I want to want to stay with Qt for > mobile applications or if I should give flutter a try. In the end, I've > decided to stay with Qt, not necessarily because it's superior to Qt, but > mainly because I know most of Qt's quirks and can write new apps pretty fast. > > Would love to hear how management sees flutter and how it possibly impacts > Qt's strategic orientation. > > Cheers > Bernhard > > > Am Mo., 18. Feb. 2019, 17:22 hat René Hansen geschrieben: > > > > > > > > > > On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge > > > > wrote: > > > > > > > > > > > On 18 Feb 2019, at 15:40, 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, > > > > > > > > > > Strictly speaking you’re not locked into using QtCreator either: I've > > > > > done command-line builds of Android apps once in a while. You can > > > > > watch what Creator does and do the same yourself. But it’s not as > > > > > straightforward as it could be, and the script I made to automate it > > > > > needs to change since earlier Qt versions. Something like > > > > > > > > > > qmake > > > > > make install INSTALL_ROOT=. > > > > > androiddeployqt --input something.so-deployment-settings.json > > > > > --output /path/to/android-build --android-platform android-27 --jdk > > > > > /usr/lib/jvm/default --gradle > > > > > > > > > > I wish we would make it a universal one-liner without having to find > > > > > paths to things first. Perhaps someone could figure out how to do > > > > > that with cmake eventually. > > > > > > > > > > > > Would definitely be nice, to have a single tool outside of QtCreator to > > > > help out for people who just like their own setup. Equate this with > > > > flutters simplicity of just `flutter run` optionally with a -d param, > > > > in case you've connected more than one device/emulator etc. Flutter has > > > > also copied homebrews `doctor` subcommand, to help you out, in case > > > > something isn't quite right. This combination of ease of setup, paired > > > > with live preview just killer. > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > I wonder how well-understood that mechanism is, so that someone could > > > > > even try to get that working with Qt? If it should not be part of > > > > > the IDE, it would have to be some daemon that watches the filesystem, > > > > > recompiles and re-deploys classes, right? But at this point it’s up > > > > > to someone to volunteer to figure that out I suppose. > > > > > > > > > > > > I'm not entirely sure how they do it, but from what I can tell they've > > > > got two separate modes of hot reload, one which reloads the entire > > > > application/world, and one where only the part you changed is updated. > > > > > > > > It might be something which is possible because of how Dart and the > > > > Dart VM itself is structured, but I'm just guessing here. As I > > > > undestand it, an entire flutter app is one big tree-like structure of > > > > widget nodes, russian-dolled into one another, so I would imagine > > > > something there allows for a recompile of a subtree, and basic node > > > > replacement. > > > > > > > > > > > > > > > > > > > There's no JS involved. It's Dart all the way. It doesn't even ship > > > > > > with a web runtime afaik. > > > > > > > > > > In other words it’s another new language all the way, but the > > > > > advantage is it gets compiled to native code. But QML can be > > > > > compiled, and anyway doesn’t depend on a web runtime. I doubt you > >
Re: [Interest] vs. Flutter
On Tue, 19 Feb 2019 at 02:57, Jason H wrote: > > Are there any good Qt vs Google Flutter comparisons? > I took a brief look, it looked like a declarative JS framework. Usually the > difference with between Qt and the competition is Qt abstracts there platform > libraries (i.e. Gstreamer vs avfoundation vs directshow) OT: This is not always a good thing. QtMultimedia is less powerful than Gstreamer for example. So if you target embedded Linux, you might prefer to use gstreamer directly instead of using QtMultimedia. Chris > ___ > 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] vs. Flutter
Just out of curiosity: Does the recent flutter 1.0 release have an impact on Qt's strategic orientation? Is flutter seen as a direct competitor to Qt? Will there be more/less focus on Qt mobile? I recently had to re-evaluate whether I want to want to stay with Qt for mobile applications or if I should give flutter a try. In the end, I've decided to stay with Qt, not necessarily because it's superior to Qt, but mainly because I know most of Qt's quirks and can write new apps pretty fast. Would love to hear how management sees flutter and how it possibly impacts Qt's strategic orientation. Cheers Bernhard Am Mo., 18. Feb. 2019, 17:22 hat René Hansen geschrieben: > > > On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge wrote: > >> >> > On 18 Feb 2019, at 15:40, 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, >> >> Strictly speaking you’re not locked into using QtCreator either: I've >> done command-line builds of Android apps once in a while. You can watch >> what Creator does and do the same yourself. But it’s not as >> straightforward as it could be, and the script I made to automate it needs >> to change since earlier Qt versions. Something like >> >> qmake >> make install INSTALL_ROOT=. >> androiddeployqt --input something.so-deployment-settings.json --output >> /path/to/android-build --android-platform android-27 --jdk >> /usr/lib/jvm/default --gradle >> >> I wish we would make it a universal one-liner without having to find >> paths to things first. Perhaps someone could figure out how to do that >> with cmake eventually. >> > > > Would definitely be nice, to have a single tool outside of QtCreator to > help out for people who just like their own setup. Equate this with > flutters simplicity of just `flutter run` optionally with a -d param, in > case you've connected more than one device/emulator etc. Flutter has also > copied homebrews `doctor` subcommand, to help you out, in case something > isn't quite right. This combination of ease of setup, paired with live > preview just killer. > > > >> >> > 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. >> >> I wonder how well-understood that mechanism is, so that someone could >> even try to get that working with Qt? If it should not be part of the IDE, >> it would have to be some daemon that watches the filesystem, recompiles and >> re-deploys classes, right? But at this point it’s up to someone to >> volunteer to figure that out I suppose. >> > > > I'm not entirely sure how they do it, but from what I can tell they've got > two separate modes of hot reload, one which reloads the entire > application/world, and one where only the part you changed is updated. > > It might be something which is possible because of how Dart and the Dart > VM itself is structured, but I'm just guessing here. As I undestand it, an > entire flutter app is one big tree-like structure of widget nodes, > russian-dolled into one another, so I would imagine something there allows > for a recompile of a subtree, and basic node replacement. > > > >> >> > There's no JS involved. It's Dart all the way. It doesn't even ship >> with a web runtime afaik. >> >> In other words it’s another new language all the way, but the advantage >> is it gets compiled to native code. But QML can be compiled, and anyway >> doesn’t depend on a web runtime. I doubt you can say that Dart has no >> runtime at all? If there is garbage collection, there’s a runtime; the >> question is which one, how big is it and what does it provide. >> > > > Yes, the Dart VM is of-course a runtime, but as far as I know it doesn't > get included in release builds, only in development, which allows for the > hot reload etc. I believe garbage collection and some other stuff from the > vm is the only thing included in release builds otherwise. > > > >> >> An advantage when a phone or OS vendor decides to support a particular >> development framework is that they can ship parts of it pre-installed. So >> the best phone for Qt applications is one that’s built with Qt in the first >> place; but the Big Two didn’t make that choice, so we can only hope that >> some not-so-small player will eventually do that (again). I recently tried >> Ubuntu Touch (yeah, better late than never): it seems quite nice, it’s just >> missing a lot of apps. There is Jolla. And there is Plasma Mobile… and >> maybe the Librem 5 will end up with Qt in some way? We’ll see. >> > > > It might be a good idea, but I'd hate having to wait on phone release > cycles/os updates, in order to get latest features/bugfixes for a Qt built > application. I don't know if any Android version even ships with native > Dart support
Re: [Interest] vs. Flutter
On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge wrote: > > > On 18 Feb 2019, at 15:40, 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, > > Strictly speaking you’re not locked into using QtCreator either: I've done > command-line builds of Android apps once in a while. You can watch what > Creator does and do the same yourself. But it’s not as straightforward as > it could be, and the script I made to automate it needs to change since > earlier Qt versions. Something like > > qmake > make install INSTALL_ROOT=. > androiddeployqt --input something.so-deployment-settings.json --output > /path/to/android-build --android-platform android-27 --jdk > /usr/lib/jvm/default --gradle > > I wish we would make it a universal one-liner without having to find paths > to things first. Perhaps someone could figure out how to do that with > cmake eventually. > Would definitely be nice, to have a single tool outside of QtCreator to help out for people who just like their own setup. Equate this with flutters simplicity of just `flutter run` optionally with a -d param, in case you've connected more than one device/emulator etc. Flutter has also copied homebrews `doctor` subcommand, to help you out, in case something isn't quite right. This combination of ease of setup, paired with live preview just killer. > > > 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. > > I wonder how well-understood that mechanism is, so that someone could even > try to get that working with Qt? If it should not be part of the IDE, it > would have to be some daemon that watches the filesystem, recompiles and > re-deploys classes, right? But at this point it’s up to someone to > volunteer to figure that out I suppose. > I'm not entirely sure how they do it, but from what I can tell they've got two separate modes of hot reload, one which reloads the entire application/world, and one where only the part you changed is updated. It might be something which is possible because of how Dart and the Dart VM itself is structured, but I'm just guessing here. As I undestand it, an entire flutter app is one big tree-like structure of widget nodes, russian-dolled into one another, so I would imagine something there allows for a recompile of a subtree, and basic node replacement. > > > There's no JS involved. It's Dart all the way. It doesn't even ship with > a web runtime afaik. > > In other words it’s another new language all the way, but the advantage is > it gets compiled to native code. But QML can be compiled, and anyway > doesn’t depend on a web runtime. I doubt you can say that Dart has no > runtime at all? If there is garbage collection, there’s a runtime; the > question is which one, how big is it and what does it provide. > Yes, the Dart VM is of-course a runtime, but as far as I know it doesn't get included in release builds, only in development, which allows for the hot reload etc. I believe garbage collection and some other stuff from the vm is the only thing included in release builds otherwise. > > An advantage when a phone or OS vendor decides to support a particular > development framework is that they can ship parts of it pre-installed. So > the best phone for Qt applications is one that’s built with Qt in the first > place; but the Big Two didn’t make that choice, so we can only hope that > some not-so-small player will eventually do that (again). I recently tried > Ubuntu Touch (yeah, better late than never): it seems quite nice, it’s just > missing a lot of apps. There is Jolla. And there is Plasma Mobile… and > maybe the Librem 5 will end up with Qt in some way? We’ll see. > It might be a good idea, but I'd hate having to wait on phone release cycles/os updates, in order to get latest features/bugfixes for a Qt built application. I don't know if any Android version even ships with native Dart support either. Maybe Fuchsia will. > > > Achitecturally it's similar to Qt, in that they've build a custom > renderer on top of Skia, so the whole scene is basically just OpenGL, which > makes it really fast. > > > > Component wise, their UI library offers bother Cupertino and Material > design out of the box, and from initial impressions, looks to be closer to > the original design guidelines than Qt Quick Controls for. e.g. Material. > > In what way? > This might just be my own personal experience, but I've run into weird and "finicky" behaviours with Qt Quick Controls, quite a number of times and so far, from the admittedly smaller sample size, I've not seen the same issues with widgets in Flutter. > > I haven't tried it out myself yet, but you should be able to reach into > native world by
Re: [Interest] vs. Flutter
> On 18 Feb 2019, at 15:40, 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, Strictly speaking you’re not locked into using QtCreator either: I've done command-line builds of Android apps once in a while. You can watch what Creator does and do the same yourself. But it’s not as straightforward as it could be, and the script I made to automate it needs to change since earlier Qt versions. Something like qmake make install INSTALL_ROOT=. androiddeployqt --input something.so-deployment-settings.json --output /path/to/android-build --android-platform android-27 --jdk /usr/lib/jvm/default --gradle I wish we would make it a universal one-liner without having to find paths to things first. Perhaps someone could figure out how to do that with cmake eventually. > 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. I wonder how well-understood that mechanism is, so that someone could even try to get that working with Qt? If it should not be part of the IDE, it would have to be some daemon that watches the filesystem, recompiles and re-deploys classes, right? But at this point it’s up to someone to volunteer to figure that out I suppose. > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. In other words it’s another new language all the way, but the advantage is it gets compiled to native code. But QML can be compiled, and anyway doesn’t depend on a web runtime. I doubt you can say that Dart has no runtime at all? If there is garbage collection, there’s a runtime; the question is which one, how big is it and what does it provide. An advantage when a phone or OS vendor decides to support a particular development framework is that they can ship parts of it pre-installed. So the best phone for Qt applications is one that’s built with Qt in the first place; but the Big Two didn’t make that choice, so we can only hope that some not-so-small player will eventually do that (again). I recently tried Ubuntu Touch (yeah, better late than never): it seems quite nice, it’s just missing a lot of apps. There is Jolla. And there is Plasma Mobile… and maybe the Librem 5 will end up with Qt in some way? We’ll see. > Achitecturally it's similar to Qt, in that they've build a custom renderer on > top of Skia, so the whole scene is basically just OpenGL, which makes it > really fast. > > Component wise, their UI library offers bother Cupertino and Material design > out of the box, and from initial impressions, looks to be closer to the > original design guidelines than Qt Quick Controls for. e.g. Material. In what way? > I haven't tried it out myself yet, but you should be able to reach into > native world by using platform channels: > > https://flutter.io/docs/development/platform-integration/platform-channels > > It's seems like it's quite a ways worse than with Qt though, so there's at > least that. What do you mean? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
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. Achitecturally it's similar to Qt, in that they've build a custom renderer on top of Skia, so the whole scene is basically just OpenGL, which makes it really fast. Component wise, their UI library offers bother Cupertino and Material design out of the box, and from initial impressions, looks to be closer to the original design guidelines than Qt Quick Controls for. e.g. Material. I haven't tried it out myself yet, but you should be able to reach into native world by using platform channels: https://flutter.io/docs/development/platform-integration/platform-channels It's seems like it's quite a ways worse than with Qt though, so there's at least that. /René On Mon, 18 Feb 2019 at 14:58 Jason H wrote: > Are there any good Qt vs Google Flutter comparisons? > I took a brief look, it looked like a declarative JS framework. Usually > the difference with between Qt and the competition is Qt abstracts there > platform libraries (i.e. Gstreamer vs avfoundation vs directshow) > ___ > 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] vs. Flutter
Are there any good Qt vs Google Flutter comparisons? I took a brief look, it looked like a declarative JS framework. Usually the difference with between Qt and the competition is Qt abstracts there platform libraries (i.e. Gstreamer vs avfoundation vs directshow) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
