[Interest] vs. Flutter

Bernhard B schluchti at gmail.com
Tue Feb 19 18:41:23 CET 2019


> 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 <jhihn at gmx.com> 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" <jereme.lamothe at qt.io>
> > To: "interest at qt-project.org" <interest at qt-project.org>
> > Cc: "Jason H" <jhihn at gmx.com>
> > 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 <interest-bounces at qt-project.org> on behalf of Jason H <
> jhihn at gmx.com>
> > Sent: Tuesday, February 19, 2019 10:25 AM
> > To: "René Hansen"
> > Cc: interest at 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 at qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190219/18640129/attachment.html>


More information about the Interest mailing list