
Announcing the Qt Automotive Suite - jrepin
http://blog.qt.io/blog/2016/06/08/announcing-the-qt-automotive-suite/
======
karmicthreat
So I'm remaking a product and was approaching qt about the commercial version.
The rep was very insistent that I can not develop an internal prototype using
the open source license and then move to the commercial license. So that makes
qt pretty unattractive to me since I have to pony up cash and hope it's good.

What I would like is something like electron that can run on a frame buffer.
What's the current state of the art for a html5 based embedded interface?

~~~
ausjke
Electron might not be "fast" enough for many serious GUI applications? That
been said, I also am struggling with finding a non-Java cross-platform GUI dev
platform. The selection pool boils down to between QT and Electron indeed
these days.

~~~
jventura
You are correct. The only serious frameworks nowadays are Qt or Electron if
you're targeting the cross-platform desktop. There's also wxwidgets, although
its python 3 bindings are still being built.

Personally, I'm keeping my eye open on libui
([https://github.com/andlabs/libui/](https://github.com/andlabs/libui/)) as it
is already possible to do some basic things with it. However, it is pretty
much in alpha state and I'm slowly writing the Python bindings for it at
[https://github.com/joaoventura/pylibui/](https://github.com/joaoventura/pylibui/).
The thing that I like in the libui is that it is a thin wrapper around
platform specific frameworks. Therefore, the library is very small (some 340
KB) and it's as native as the underlying platform calls are..

Regarding Electron, I am writing an application on it, but it is too god damn
heavy in terms of memory, disk space and boot time, and web front-end
development is absolute chaos these days. Although I'm currently writing my
app on it, it is mostly an MVP as I want to make pylibui/libui usable enough
to switch to a pure desktop cross-platform library asap..

~~~
c-smile
"Regarding Electron, I am writing an application on it, but it is too god damn
heavy in terms of memory, disk space and boot time,"

Try Sciter HTML/CSS engine then ([http://sciter.com](http://sciter.com)). It
is a monolitic DLL (4-8 Mb) without external dependencies. Works on
Win/Lin/OSX and even on Raspberry Pi 2 - [http://sciter.com/sciter-on-
raspberry-pi-2/](http://sciter.com/sciter-on-raspberry-pi-2/)

~~~
jventura
Thanks for the suggestion, I didn't knew about this before! So I've tried it,
the lib is small (~9MB on OS X), it renders pretty fast and has python
bindings which is quite great.

However it lacks in some areas, such as the scrolling which is quite bad, and
it does not render the SVG files that I'd need it to render (tiny SVG spec,
but lots of defs and rotations). I'm still going to look better into it since
I can use Cairo and CairoSVG to convert my SVGs to PNGs, but I still do not
know how well it renders some css rules, fonts, etc..

------
distances
As far as I know, almost all independent (meaning manufacturer proprietary, so
disregarding Android Auto here) user-facing in-car systems are using either
HTML5 or Qt. In that light it sounds like a smart move to make it even easier
to pick their offering.

------
pjmlp
Interesting the focus on QML.

It feels like the Qt Company is pushing C++ down the stack, with QML getting
the main focus as application development language.

~~~
giovannibajo1
I don't think it has to do with language but rather with interface patterns.
Qt Widget was made to do native desktop apps like Word; QML was made to do
touch apps like on mobile. Embedded has shifted to adopt touch screen and copy
interface patterns from mobile (where touch based interface were innovated
first).

You don't want a Word-like app in your car dashboard, but a iOS-like app.

~~~
pjmlp
Except that on iOS you can do everything in Objective-C/Swift if you feel like
it.

Same applies to Android, UWP and even Tizen with their respective native
languages.

So it is a conscious decision not to provide C++ APIs besides the old QtWidget
and make developers use QML and its compiler instead, as far as I understand
it.

~~~
distances
It's not as clear-cut as that. This is a case for automotive, and there isn't
a single native UI widget set that Qt could use/mimic. It absolutely makes
sense to use QML for custom UI development, it really shines there -- using Qt
widgets for custom UI on touch screens would be madness.

I've used Qt myself for desktop, mobile, and embedded development. For mobile
and embedded I would _not_ use widgets, and probably not even for desktop. I
understand why the widgets still has staunch fanbase, but they do not belong
everywhere.

