[Interest] vs. Flutter

René Hansen renehh at gmail.com
Mon Feb 18 17:18:36 CET 2019


On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:

>
> > On 18 Feb 2019, at 15:40, René Hansen <renehh at gmail.com> 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 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?
>


That it's very easy to wrap a native library in Qt and expose it to
QtQuick, since your entrypoint is native and not the other way around.
Again, I haven't experience outside of going over the docs, but platform
channels doesn't seem like much of step up from e.g. doing straight JNI
yourself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190218/3d2c2098/attachment.html>


More information about the Interest mailing list