[Interest] vs. Flutter

Mon Feb 18 18:08:55 CET 2019

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 <renehh at gmail.com> geschrieben:

>
>
> 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.
> _______________________________________________
> 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/20190218/0d723078/attachment.html>