
Technical Vision for Qt 6 - pjmlp
https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/
======
dkersten
"Make JavaScript an optional feature of QML." and "Support compiling QML to
efficient C++ and native code."

Yes! These two things are what's been on the very top of my wishlist ever
since QML/QtQuick was first released.

~~~
stabbles
I would love this!

In fact the QML format would not even be a terrible way to write non-UI
applications, I'd think. Something like

    
    
        MySqlDataBase {
          id: default_db
          host: ...
        }
    
        UserController {
          items_per_page: 20
    
          formatter: UserFormatter {}
    
          repository: Repository {
            table: "users"
            database: default_db
          }
        }
    

is definitely more easier to follow than the linear version

    
    
        auto default_db = std::make_shared<MySqlDataBase>("...");
        auto userformatter = std::make_shared<UserFormatter>();
        auto repository = std::make_shared<Repository>("users", default_db);
        auto controller = std::make_shared<UserController>(20, userformatter, repository);
    

especially when you do some kind of constructor injection with nested objects.
The declarative tree structure of QML is great.

~~~
halflings
It doesn't look as bad if you skip the intermediate variable declarations,
since you're not re-using those variables elsewhere.

(the QML structure only works as long as this is the case, e.g clear nesting
of instances)

~~~
dkersten
> clear nesting of instances

You can have references (default_db in the example) to instances to have
indirectly nested instances too.

------
jupp0r
Thanks for supporting CMake and deprecating qmake. Not that cmake is the best
tool ever, but having to deal with several build systems in the same project
has always been a nightmare.

~~~
halflings
Would have hoped they would use bazel instead. It's open-source, and so much
easier to deal with than CMake.

~~~
4ad
Are you kidding me, bazel is written in Java...

~~~
malkia
so what? Bazel spawns a server, the next invocation is really fast.

~~~
tonyarkles
You’re not helping your case! Spawning a server (a JVM-based one at that!) to
be able to get reasonably performant builds is horrifying!

As a simple example, I hack on a Qt app on a Raspberry Pi (it has a tiny
display on it and I run a dashboard). It’s only got 512MB of RAM and spinning
up a JVM server to run my builds will likely cause it to run out of RAM. I’m
not the world’s biggest fan of CMake, but it sure solves a lot of problems
while being quite lightweight. And I’ll take it over qmake, mostly because I
know CMake well enough and haven’t ever really gotten into the guts of qmake.
CMake is more general purpose.

~~~
malkia
I don't get why are you saying it's horrifying. It keeps cached copy of the
build graph, among other things, so subsequent invocations of the build
systems, there is less to read cold again. It's pretty good design. Also the
server dies after some time (controlled by some default). MOC/UIC/RCC would've
integrated much easier there, than what's right now.

~~~
tonyarkles
How much memory does that take, vs something like CMake that starts cold? I
can see why you'd want to do that if you have an absolutely massive dependency
graph for your build, but outside of a few select companies, that's probably
not the case.

~~~
malkia
Honestly I haven't measured, ballpark figure would be hundreth megabytes to
gigabyte. Given that it's standard on dev/build machines to have more than 8GB
I don't see it as a problem. Memory is cheaper these days than developer's
time.

------
Crinus
I hope they fix QtDesigner to not be hot garbage. Elementary operations such
as trying to move some controls to a container that has zero size is totally
unintuitive (you need to alt+drag to the container in the widget tree view -
note that nothing else needs that) and not always possible (the widget tree
view doesn't scroll so if the container is out of view you can't move stuff
there - the fact that selecting something in the form automatically selects it
in the widget tree view _and scrolls it_ doesn't help at all there), or simply
pasting widgets in a container without breaking the existing layout
(literally, the program tells you to "break" the layout... meaning to remove
the existing layout). Or something like making a widget invisible (the visible
property is not exposed in the property editor and if you force it to be
enabled and mark the widget as invisible then the widget doesn't show up in
the editor :-P).

And some widgets are simply missing or accessible through obscure ways (e.g.
instead of QSplitter being in the Containers group in the widget box, it is
only accessible by ctrl+clicking two controls under a parent container that
has no layout and right clicking and selecting selecting Layout
horizontally/vertically (two menus) - WTF, what is wrong with simply letting
me drop QSplitter in the form and then place controls manually? I can already
do that perfectly fine after i perform the magic incantation to bring it in -
though of course i cannot change the splitter position from within the form
editor, because that would be too convenient i suppose).

I've seen form designers from open source projects written by a single
developer in their free time that are more polished than that. The only thing
worse is writing those UIs by hand.

~~~
jimbo1qaz
I prefer writing UI by hand, rather than using Qt Designer. In C++, I figured
out a few simple macros to automatically redefine `auto w` and `auto l` to
refer to the parent widget and layout.

Is there a reason Qt Designer generates .cpp files which append a child to the
parent _after_ the child is fully fleshed out, rather than when the child is
first constructed? Does the latter approach create too many relayouts, or did
it do that in the past? I tried to replicate that design quirk in my code, and
had to use RAII to "add child to parent at end of scope", even though I don't
want the destructors to run if an exception occurs during UI layout.

~~~
slavik81
I doubt order matters much. Typically you call setupUI() and then show(), so
the widget is hidden during initialization. I don't think any layout work
actually occurs until the widget becomes visible.

------
danielscrubs
“should as such not be disruptive to our users” and “Elements of artificial
intelligence will be more commonly used in applications and devices, and we
will need to have easy ways to integrate with those.” told me everything I
need to keep away.

Focus QT! What do you want? Do that well.

~~~
monocasa
I mean, the second one makes sense to me. Medical loves QT, and I can see them
wanting easier integration of visual recognition models (think "detects breast
cancer on an MRI" models) with the GUI. I could totally see wanting to really
easily plug and unplug different models and overlaying their results, bringing
you full circle to the GUI. Basically easier integration with complex heavily
multipass GPGPU visual results.

~~~
danielscrubs
Can you explain what you mean? Normally you just send in the pic to Tensorflow
that then uses the gpu, where would QT enter the picture that would be more
than two lines of code?

~~~
wwright
TensorFlow needs a lot of scaffolding for managing the lifecycle of data/&c. A
big attraction of Qt is that it is often more like writing Java than C++.

------
GnarfGnarf
I'm converting a 500KLOC C++ consumer app from Win32 to Qt so it can also run
on macOS. All the app-specific code remains the same. I'm very pleased with
how easy it is to design dialogs. Qt is better than anything Microsoft has to
offer; what would entice me to forego portability?

~~~
pjmlp
Have a try at WPF/WinUI, Blend tooling and the myriad of companies selling
ready made components.

Otherwise, yes Qt is the best option for cross platform C++ code.

~~~
GnarfGnarf
@pjmlp Thanks for the suggestion. I can see using WPF/WinUI for corporate-type
apps where it will run under Windows on thousands of desks. However, if
WPF/WinUI doesn't run on macOS, there is no incentive to use it for consumer
products. When I do customer presentations, the number one question is "When
will it run on the Mac?"

~~~
pjmlp
Maybe sooner than we would expect, but it will take a while still.

[https://devblogs.microsoft.com/dotnet/calling-all-net-
deskto...](https://devblogs.microsoft.com/dotnet/calling-all-net-desktop-and-
mobile-developers/)

------
jlarocco
It's good to see language compatibility mentioned, and I hope they follow
through with it.

There were really fantastic Common Lisp bindings for Qt4, but they relied on a
tool called "Smoke", which stopped working with Qt5. My understanding is Smoke
was used to create the early Python binding, but a different mechanism was
used for the Python bindings in Qt5. For some reason the new technique wasn't
as easy to use from other languages, so a lot of alternative language bindings
stagnated on Qt4.

I don't know if it's improved lately, but between using C++, the non-standard
moc pre-processor, qmake, and little support from Qt itself, it's really hard
to generate bindings for Qt now.

~~~
sime2009
Here's a quick history lesson. Long ago Smoke was created by one guy, Richard
Dale, to do bindings for Ruby (QtRuby). Smoke was generic enough to be used
for other languages like Lisp and also the .Net CLI. Language bindings other
than Python didn't really catch on and the community needed to make it all
viable and self sustaining didn't emerge. It was mostly one person's passion
project and they didn't get any real help. So it died.

PyQt (Python) came from a small one man company in the UK called Riverbank
Computing. It is mature and has been around for a long time. It used a custom
tool called SIP for the bindings. Last time I checked it was still around.

In the Qt Nokia era, a team was assembled by Qt to create official Python
bindings to compete with PyQt. IIRC they used Swig to do it. Then they lost
funding for a few years before being revived in some form at which point they
were busy moving to their own home grown binding generator.

~~~
cmaureir
And that binding generator is called Shiboken, which was motivated by
boost::python and the same idea behind the binding generator written for Java
in the old days (from QtJambi).

At the moment Shiboken is more general, and mature and can be used even for
C++ projects (which are not related to Qt).
[https://wiki.qt.io/Qt_for_Python/Shiboken](https://wiki.qt.io/Qt_for_Python/Shiboken)

------
pippy
These changes are very welcome, but in my opinion are too little too late. Qt
has missed the boat with the current developer mindset. While I want Qt to
'win', as the end result is superior to say an electron app, most developers
are willing to sacrifice usability and add bloat by using electron. Or simply
paint them selves into a corner with a native SDK.

Qt has a massive uphill battle to try and stay relevant. Like it or not,
there's a reason why electron apps and native ui sdks become the zeitgeist.
While reusability is often cited as the main reason why electron has become
the cross platform defacto, there's a lot more to it than that.

Personally, the difference between using electron and Qt is black and white.
Looking at setting up alone, With Qt you have to struggle to compile a massive
library which inevitably won't work. After sinking hours into compiling it,
you're confronted with a unknown markup language and toolchain just to get a
window displaying. And the documentation is incomplete, and to top it all off
the minor versioning differences will cause your app to break in spectacular
ways. Compare this to electron, where everything just works out the box, and
with npm you have every single library you could ever think of. Microsoft and
Apple roll out the red carpet for developers to make ui development super
easy, so making two apps with a shared library is often just as tempting.

The way I'd try and save qt would be to make a react-native binding a first
class citizen and ditch QML/js engines. I'd also remove the custom tool chains
and release extensions for VSCode/Atom that outputted jsx that could get
interoperated by a virtual dom. developers would kill for that.

~~~
sho_hn
I respect your comment, but I think it's a narrow look at what Qt is and what
it's used for.

You mentioned "native UI SDKs" having become preferrable, but keep in mind
that in many scenarios, Qt _is_ the native UI.

On desktop Linux there isn't a lower level toolkit Qt is translating to, but
also in the many embedded products Qt is used on: Car and aviation
infotainment (a prominent example is Mercedes-Benz' MBUX OS, but there's
literally dozens of these built on Qt and shipping), medical equipment,
industrial machines (e.g. the entire HMI sector), kiosk systems, coffee
makers, ... Qt is an excellent choice for these, often the only one, and the
web stack is very unattractive there due to performance/hardware overhead,
quality, security, etc. They're product use cases in industry, with a lot of
available very high-paying jobs.

And it's worth keeping in mind that the use cases I cited above by and large
pay better than making desktop software does today, unless you're an
entrenched player like Autodesk (which uses Qt doe many of its apps). In the
only "this pays for a decently sized staff of engineers" desktop app products
that are new that I can think of, Qt is also still doing well - say, Pix4D's
apps for drone mapping/photogrammetry - because they likewise solve hard
problems where you don't want to deal with the web API abstraction/quality
barrier and performance overhead.

My bottom line here is: Right now, and very likely ten years from now, if you
are good at at Qt you're probably going to work in a very good and stable job
at a solid business. I don't see this being the case for Electron developers,
and I know where I'd rather be.

As for making desktop apps, if your experience is "Looking at setting up
alone, With Qt you have to struggle to compile a massive library which
inevitably won't work" it shouldn't be ignored and the developer experience
should be improved - tooling, build system and getting modules to devs are all
mentioned in this blog. However, I have to say this has never been my
experience - between Qt being packaged in Linux distros and the SDK installer
on other platforms it's never been hard to set up Qt for me.

~~~
sime2009
> My bottom line here is: Right now, and very likely ten years from now, if
> you are good at at Qt you're probably going to work in a very good and
> stable job at a solid business. I don't see this being the case for Electron
> developers, and I know where I'd rather be.

What?! If you're specialising in Qt then your skills are tied to Qt and you
are tied to the health of the Qt job market. Those skills are not very
transferable. On the other hand, 90% of the skills needed for Electron
development are web technologies which are relevant to the massive web related
job market. I know where I'd rather be.

~~~
0lpbm
> Those skills are not very transferable.

I think you are very wrong. Qt is just a bunch of C++ with preprocessing.
Knowing C++ is a very transferable skill.

~~~
sime2009
Yes, I'm fully aware of what C++ is. I'm talking about Qt skills specifically.

My point is that in Electron development, the Electron specific skills is very
small part of development. Most of the skills and tools used are also widely
used elsewhere in industry. This is not the case for Qt work.

------
azhenley
I'm looking forward to doing a comparison of Qt 6 and Electron in terms of
both usability and performance.

~~~
pjmlp
Easy just watch React Native for Windows talk at Microsoft BUILD 2019.

Electron has 700% performance lost over UWP/C++, which is the baseline.

Expect similar results when comparing against Qt.

~~~
rat9988
I had to search for the video, but I guess you are talking about this?

[https://youtu.be/TZnajQqqKV8?t=2894](https://youtu.be/TZnajQqqKV8?t=2894)

~~~
pjmlp
Yep, that one.

------
mkesper
Would there be a chance of rust integration with these stronger types they
mention?

~~~
rhn_mk1
There are a couple of projects attempting Rust integration with QML. In
particular, I forked Jos van den Oever's seemingly unmaintained bindings
generator:

[https://gitlab.com/rhn/rust-qt-bindings-
generator](https://gitlab.com/rhn/rust-qt-bindings-generator)

It's for Qt5, and I think I know how to achieve strong typing (just turn
everything into different QObjects, they don't get converted), but haven't
implemented that idea yet.

------
lousken
HN hug of death? [https://archive.is/VVpgQ](https://archive.is/VVpgQ)

I just hope they gonna keep memory footprint as low as possible so I can keep
bashing electron devs.

~~~
jcelerier
> I just hope they gonna keep memory footprint as low as possible so I can
> keep bashing electron devs.

well, they want to focus on microcontrollers apparently :-)

------
zerr
I hope QML/js crap will be abandoned, and C++ API will be prioritized.

~~~
ungzd
C++ (and even Rust) is not the best language to build UIs. Even if your app
heavily uses C/C++ to do heavy computations, "scripting" language will be
preferable for "glue code". QML is not a crazy new idea, for example Tk used
Tcl.

And due to C++ API, Qt has poor language bindings, compared to GTK and many
others with C API.

~~~
blub
I believe you're incorrect, C++ is a good language for building UIs, as proven
by the plethora of UI libraries and frameworks built in C++ for pretty much
all platforms. This is visible when comparing PyQt and C++: yes, PyQt is
easier to get into, has nicer syntax, but C++ offers more power. Even hot-
loading UIs, a typical scripting language advantage is supported.

Declarative UI languages do have some advantages compared to regular
programming languages, but that's unrelated to the claim you made.

Bindings are not C++'s problem, they're the problem of the other languages
which try to use UI frameworks written in C++, like Rust, which still doesn't
have any decent UI library.

~~~
pjmlp
They have the graphics layer written in C++, but get used from managed
languages.

QML, Swift, Android, UWP, WPF, Forms, Blueprints, Unity, React Native.

~~~
jschwartzi
I've worked on two products with touchscreen UIs now and I can safely say this
is exactly how I want to do things. Have a tight core engine but with a
flexible declarative language that I can get imperative with. And make it easy
for me to declare connections between the model and the view without
specifying data types. And give me a way to work with a statically typed
language when that's beneficial.

QML is way faster to develop in than C++. And it hides a lot of signal/slot
boilerplate that doesn't matter. And I can still write C++ classes that
interface with QML when I want.

------
hawski
I hope for the overlap of their TypedQML with TypeScript. I am a C++ dev by
career and had recently an opportunity to use TypeScript. It's quite nice. It
has it's warts as it's structural typing, because of limitations within
implementation goals - type erasure and being JavaScript but with types. As
much as I would like to see TypeScript Native it's probably to difficult to
marry JavaScriptness with relative ease of compilation to C++. Hopefully Qt
effort could be extended beyond Qt itself and that would be something I would
look forward to.

------
ktpsns
I wonder whether Qt could get rid of the C++ moc preprocessor. There are
wonderful native signal-slot libraries for C++, and RTTI, introspection and
reflection are either there or about to be standarized.

------
kart23
Can someone please show me how to style a qt app relatively easily? I've built
qt applications, and making some effort to make it look passable takes twice
as much time as actual programming. QSS just sucks in making luxurious feeling
interfaces, and this is where electron succeeds. Its much easier to make your
own 'widgets' and have a great feeling application at the expense of ram and
performance on electron. If Qt fixes styling, I would be onboard 100%.
Performance is amazing and I like being able to develop one codebase for all
operating systems.

~~~
anmorgan
This is geared towards qtquick (not widgets) applications, but to create a
general theme you can use this pattern:

[https://doc.qt.io/archives/qt-5.11/qtquickcontrols2-flatstyl...](https://doc.qt.io/archives/qt-5.11/qtquickcontrols2-flatstyle-
imports-theme-theme-qml.html)

Then before the engine is loaded in main.cpp call

qmlRegisterSingleton( QUrl(QStringLiteral("qrc:/Theme.qml")),
"mycustomname.theme", 1, 0, "Theme");

Then in a qml file:

import mycustomname.theme 1.0

This allows you to do something like:

Rectangle { width: 100 height: 100 color: Theme.mainColor }

You can also do things like set the application font which would be done in
main.cpp before the engine is loaded:

QFont appFont("NameOfLoadedFont); appFont.setPixelSize(16);
QGuiApplication::setFont(appFont);

You would need to load the font, which you can do in the Theme.qml file:

property FontLoader someFont: FontLoader { source: "qrc:/locationOfFont/Font"
name: "NameOfLoadedFont" }

------
amelius
Any ideas in Flutter or React that might be useful to have in Qt?

~~~
yakubin
Where did this question come from?

~~~
mkl
GUI frameworks borrow ideas and innovations from each other all the time. It's
a totally normal thing, and hence an obvious question.

~~~
yakubin
Yes, but I would expect that there is a particular aspect of a framework one
might be interested in seeing adopted in another framework. But asking what a
random framework X has to offer for framework Y, when framework X wasn't
mentioned anywhere previously is unexpected. It's like seeing under the
release notes of a new linux kernel version a question "any ideas from windows
that might be useful in linux?". I'm probably overthinking it. :)

------
vunie
I hoped there would be more focus on how their web assembly support will be
improved (specifically, how they intend to handle the narrow viewports of
mobile devices).

Web Assembly QT enables a really nice way for customers to mess with an app
without installing anything on their systems. It works with Q5\ _, but a still
has much to be improved.

\_ with a bit of modification to QT's output.

------
wpdev_63
Their tricky licensing makes using Qt for personal projects a non-starter and
anything commercial really hard to justify.

If they streamlined the licensing and created (C)sensible language bindings
then it would be great. I tried the python bindings and they were problematic.
Can't even imagine using one of the unsupported bindings.

------
shmerl
They should add official Rust bindings.

~~~
oehtXRwMkIs
is it possible to have safe bindings for something like Qt? never understood
if that's a thing or not since I've heard FFI usage is inherently unsafe.

~~~
shmerl
I assume if the logic is wrapped into something that handles it correctly, you
can declare it as safe, even if inside it's unsafe.

~~~
lkschubert8
Yeah, unsafe doesn't have to pollute callers (async in C# is a good example of
something that does)

------
musicale
I have given up on Qt since it doesn't work efficiently with X11. GTK works OK
though.

~~~
rossy
Eh? X11 is probably Qt's best target, and it's one of the most popular
toolkits for building X11 applications. What made you think it wasn't
efficient?

~~~
Spivak
Check out
[https://bugreports.qt.io/browse/QTBUG-50338](https://bugreports.qt.io/browse/QTBUG-50338)

They made a choice that was good for local rendering but because it sends full
bitmaps to the X server to display it uses a lot of bandwidth which killed
performance when forwarding X applications over the network.

I'm _personally_ of the opinion that today's X is only accidentally network
transparent and a bad remote desktop solution but I don't deny that it's part
of a lot of peoples' workflows.

~~~
rossy
Right, that makes sense. I didn't know they removed QT_GRAPHICSSYSTEM=native
in Qt5. I'm of the same opinion as you, but I can see why it would be a
problem for some. (For some reason we still had to use Solaris X terminals in
my first year of university.)

------
badsectoracula
Does that mean all current KDE applications will soon become binary
incompatible with the future KDE libraries that will be based on Qt 6?

~~~
mkl
KDE applications and KDE libraries will be updated together. How else could it
be?

It won't be soon, either. Qt is aiming for a first release of Qt 6 by the end
of 2020.

------
phkahler
Why a scene graph? I had the same question about GTK 4 and have yet to see any
sensible answer.

~~~
iso-8859-1
Declarative layouting is in fashion, which works well with scene graphs.

GUI frameworks have usually been tied to inheritance-based object oriented
systems.

~~~
pjmlp
It is fashion because on modern GPUs is easier to optimise what actually needs
to be done, and combine passes as well.

During the early days of GUI development, immediate mode won because scene
graphs are more demanding in regards to memory consumption, and graphic chips
were quite limited anyway.

------
haspok
How about direct support for modern, UI-focused languages like Swift and
Kotlin?

------
thebruce87m
Any cheaper licensing options for us embedded folk?

------
SubiculumCode
Could someone please please fix vncserver to properly display applications
using qt?

------
Areading314
Have you considered rewriting it in Rust?

~~~
oehtXRwMkIs
Honestly at this point they should just rewrite it in Javascript and focus on
javascript bindings. Javascript is simply more productive and friendlier for
devs to work with. This would allow Qt to compete with Electron for how well
my hands are kept warm by my laptop during the winter.

------
notathing
What Qt needs is more Electron.

Please show me one major new desktop application written today which uses Qt.
Major meaning used by millions of people.

~~~
blub
Popular doesn't mean good. In fact Electron is born out of the idea that
developer productivity and comfort is everything and performance is a
secondary concern.

These apps seem to be popular with device manufacturers. I have the
displeasure of using two such apps, both have crap usability and custom UIs
that don't make any effort to integrate with the platform. One of them doesn't
even respond to the quit shortcut.

~~~
notathing
> These apps seem to be popular with device manufacturers.

All apps written by device manufacturers are crap, regardless of what they are
written in. It has nothing to do with Electron, just with the fact that they
only know how to do hardware, and are clueless on the software side.

~~~
blub
The apps function correctly, it's the UI that is the problem.

It's modern looking, but obviously not native and doesn't respect some
platform idioms or shortcuts, so all in all it's a subpar experience. This is
completely related to Electron and would not happen for a native app, where
the framework takes care of the look & feel and integration.

If every app were written like this, we'd end up with scores of slightly
inconsistent apps, all of them trying to be unique and cool and resulting in a
mediocre platform. i.e. Windows.

