
A Book about Qt5 - geezerjay
https://qmlbook.github.io/
======
jyriand
I have been thinking about creating a desktop app for a while now. Problem is
I can't decide which framework to use. Ideally I would like to use Common
Lisp, but McCLIM looks like it's from the eighties, there's also qtools and
CommonQT that make it possible to use Qt in Common Lisp, but somehow I'm
afraid to develop myself into corner with these tools. Could also use clojure
and "seesaw", but again -- it's like I'm handicapping myself here. I could use
Racket and it's GUI library, but Racket is marketed as a language for creating
languages, so I'll skip that. I guess I still need to use Java 8 with JavaFX.
I wish there was a lisp dialect just for developing desktop applications.

~~~
oblio
Yeah, it's a real shame. From what I see the best Common Lisp compilers and
libraries are proprietary and seem to be stuck a in 90's vendor (think
Borland) mindset.

They're probably serving their existing customers well, since they're still
around, but I doubt they're getting many new customers (or mass adoption) with
these prices:
[http://www.lispworks.com/buy/prices-2c.html](http://www.lispworks.com/buy/prices-2c.html),
[https://franz.com/products/packages/](https://franz.com/products/packages/).

~~~
lispm
Probably they wouldn't get 'mass adoption' with lower prices either. Devtools
is a niche market and for an independent company it is difficult.

See for example the price for VA Smalltalk...: $6995 for a new developer
license.

[https://www.instantiations.com/products/purchase.html](https://www.instantiations.com/products/purchase.html)

Or VisualWorks, which charges based on either end users, number of CPUs, or a
royalty basis.

It's a special niche market and in the Lisp space there are unfortunately no
companies left of those which once sold actively maintained mid-priced Lisp
systems with actual GUI Libs/IDEs (Dead/sold/abandoned/unmaintained: Procyon
CL, Expertelligence ExperLisp, Corman CL, Digitool's MCL, Golden Common Lisp
from Gold Hill, ...).

The remaining ones are two of the higher-priced vendors: Allegro CL and
LispWorks. There were attempts to offer commercial CL systems - but none with
emphasis on GUI (example Scieneer CL).

------
mattigames
I still remember the amount of pain I went with trying to use Qt5 on python,
the compile errors, the compile times, the differences between what QtDesigner
showed and the actual output, made me appreciate CSS and SASS a lot more.

~~~
rolleiflex
Same here. I designed and built the first version of Aether with Qt5 via
Python. It was a miserable experience where the only way to solve certain
things were to insert non-meaningful text into certain magic Python fields
which would go and compile in C++. Plus a few hundred iterations of getting
the magic incantations to work in a consistent manner.

For the second version — I've moved to Electron for UI and Go binaries for
actual heavy lifting. At least that one is a known pain you can Google for.

~~~
qwerty456127
Indeed lack of a good (Tkinter just doesn't offer all the necessary widgets,
looks and feels clumsy) modern pythonic GUI toolkit seems the biggest problem
of Python to me.

Nevertheless I'm surprised to read you had to compile anything (if you don't
mean using pyuic5 to generate Python classes from QtDesigner XML files) and
deal with C++ while using Qt5 with Python.

~~~
pjmlp
They are now investing into Python as official supported language.

[https://www.qt.io/qt-for-python](https://www.qt.io/qt-for-python)

~~~
mk89
Well, it was about time. Pyside is a quite old project that for a while almost
seemed to have fallen into oblivion. Glad to see that they are finally using
it as official binding tool.

------
pknopf
This page mentions using Python.

I also went to mention that you can now use .NET/C# with QML as well.

[https://github.com/qmlnet/qmlnet](https://github.com/qmlnet/qmlnet)

PS: I'm the author.

~~~
Waterluvian
Hi author!

When I used Qt4 years ago, I ran into a lot of issues regarding segfaults and
generally issues with the underlying C++ objects. Admittedly this was largely
my fault, but I did find that I had to worry about the underlying
implementation a lot and not think idomatically in Python as much.

Have things improved?

~~~
pfranz
The specifics get a bit annoying and pedantic. I'm guessing you were dealing
with Qt4, PyQt, and Python2? PyQt was a separate thing written by Riverbank
Computing (sip was the binding interface). The bummers were it wasn't open
source and had separate licensing. In 2009, the Qt people (Nokia at the time)
released PySide. Shiboken is the new binding interface. It was mostly
compatible with PyQt, open source, better license, and was more idiomatic with
Python (Python unicode strings instead of QString, more decorators on
functions instead of having to call specific functions in a specific way).

Qt5 was released in 2012. A lot of the user-facing focus was on QML. QtWidgets
(the only part I'm familiar with) are now considered "feature complete." That
means they're not deprecated, but not getting any new development. PySide2 is
PySide with Qt5 support. That took awhile (especially to get Python2 support)
and PySide2 was later branded "Qt for Python" even though the imports are
still "pyside2." During this time many people transitioned to Python3.

Sorry to throw out so many things. A lot has changed, not all of it might be
relevant to you, but I figured I'd mention them so you have a reference point
if you want to jump back in or look more into what has changed.

Now to actually address your question. Pyside2 is a pretty big step towards
making Qt more idiomatic to Python. I can't speak definitively on the rest of
the transitions, but I don't think much has changed. Maybe QML and Python3 are
more idiomatic?

After using them for a decade, I feel like idiomatic Python just doesn't have
the constructs needed for an event driven gui so it has to lean on C++ and
other things Qt built. Or Qt integration was done so long ago, it wasn't built
around newer Python things like asyncio. I also can't speak too much to
Python3 since my day job still uses Python2/PySide2/Qt5, but I've been looking
at the new Python3 packages for years. Unfortunately, I feel like a lot of the
async stuff added to Python isn't as terse and elegant as seeing something
written in C ported to Python. Maybe I need to recalibrate what I think of as
"Pythonic" when I get to use Python3 day-to-day?

As an anecdote of Python lacking necessary constructs, I've stumbled on co-
workers using parts of QtCore outside of any GUI because it was the best
library they had handy. I wish I could remember some of the use-cases, though.

~~~
toyg
PyQt has always been open-source - it’s dual-licensed under GPL 2 and
commercial.

What you meant to write probably was “PyQt is not free to use in closed-source
applications”.

------
shaan7
For folks who are new to Qt5 and are wondering how an app looks in production,
we have a screenshot at
[https://www.sostronk.com/app](https://www.sostronk.com/app)

We released SoStronk's desktop app using Qt5 in 2014 and its going great today
as well. Having had ~5 years development experience with this, I'll be happy
to answer any questions :)

~~~
wjoe
That looks great, but very different to what I've seen from playing around a
bit with Qt.

Are you using some open source theme or components there, or is it very custom
built? I felt that Qt Quick Controls 2 felt far too mobile focused when I
tried it out, and looked/felt very out of place in a desktop application, but
I guess if you're customizing it heavily then that's less of an issue.

I notice you're only providing a Windows download despite Qt being cross
platform. Are there any blockers or issues in building the same app for
Mac/Linux, or is that just not something you've looked at. I guess the latter
since it's for a game, but just interested since I've seen a lot of comments
in the past about difficulties making Qt apps run consistently across
different platforms.

Are you using QML and JavaScript for all of the application code, or just
using that for the UI and handling the main logic from C++ or other language
bindings?

Any thoughts on the Qt/QML approach compared to Electron?

~~~
shaan7
The controls themselves are standard Qt Quick Controls 2 items. We didn't need
to invent anything new. However, we do have custom styling for each control
(buttons, checkboxes etc). If you want a native desktop look'n'feel then you
should use QtWidgets instead. In our case it was an explicit requirement to
have a custom theme from our design team.

We have internal builds on Mac/Linux for our own use but its not useful to
release it to our users as our Anticheat software is Windows-only. In other
words, we can release a package for Mac/Linux for the Qt app itself, but not
the Anticheat (without which players cannot join the game servers). For the
internal builds, we generate .dmg using macdeployqt and .deb for Ubuntu.

QML and JS are used mostly for the UI interaction, all heavy lifting
(populating models, user information, lobby statemachine etc) is done in C++.

As for Electron, I haven't personally used it for development so I cannot
compare the development differences. There are obviously more libraries
available for the JS/HTML world* but on the flip side using Qt/C++ has made it
very easy to keep the app lightweight with just a ~1.5man dev team. Players
must keep the app open alongwith the game so we need to be very conservative
about resource consumption.

*But then, Qt adds support for some of them. The most recent example being QtLottie.

Engineer hat off, I wish that more popular desktop apps were made using
dedicated tooling (Qt, .NET etc) instead of cramming a UI inside a browser
engine just because its "easier".

------
cheez
QML is fantastic. I use it for a commercial application of mine. Main
difficulty is finding someone to implement designs but I can do that myself if
push comes to shove as I don't need to do a full redesign every 6 months.

------
sickcodebruh
I know nothing about Qt beyond the most basic description but I’m interested
in exploring it as an alternative to Electron. I see lots of debate in the
comments here but limited context to help me understand what is being debated.
Is this book for me? What background should I, a total beginner, be aware of
before I dive in?

~~~
sonnyblarney
Qt is a _very comprehensive_ system for apps developed mostly in C++. QML
which is like a declarative Javascript, can be used to do quite a lot, but
you'll almost certainly need to do some C++ customization in addition to the
initial basic 'main app' process which requires C++ as well.

Many of their customers use it for display/kiosk things (think 'in car
display') so it has a lot of hyper-specific attributes which can make it seem
a little difficult.

The build process is ultimately C++ based (ie make, with their own layer
called 'qmake') and so you're going to have to be familiar with that.

In our experience it's quite slow moving compared to JS/CSS/HTML obviously,
and performance gains are very situationally dependant.

~~~
sickcodebruh
Thank you! That’s helpful. Since you’re comparing it to JS/CSS/HTML, does this
mean you moved from that to Qt? If so, do you think it was a worthwhile move?

When you say many of _their_ customers, who is they? Qt or the people
responsible for QML?

~~~
sonnyblarney
I've used both on projects. HTML5 is comparable really when used in
combination with Electron for example, i.e. to make an installable app. Surely
you're aware of the limitations and challenges of HTML5, i.e. you can move
quickly, but it's full of quirks. Electron is a little heavy.

Qt I would use if performance was a concern, i.e. there were imaging
algorithms, or if the hardware platform were non-standard.

Yes, Qt's customers are auto-companies etc..

Qt is complex and it's a kind of a big step, and it's in C++ which is always a
lot slower to move in, however it is powerful, there's really no other
comparable.

~~~
sickcodebruh
Perfect, thank you. More and more, Qt sounds like the right fit for the
product I work on.

~~~
sonnyblarney
Adding this now in case you read it: try not to underestimate how different
and challenging the world of C++ and their extensive libraries can be.
Literally they use QString, QVector i.e. their own, custom building blocks due
to the crazy fragmented nature of the C++ world. The development approach is
totally different and the kinds of devs you have to hire are totally
different. They need to be much stronger, at the same time, focused on
actually creating outputs and getting stuff done because you can easily get
lost in C++/Qt. Oddly, most people who have experience in HTML5 are pretty
close to the UI/design/user aspects to begin with, which is a different
culture than most from the C++ world. And as I say the performance issues are
totally situational.

For any kind of regular business app or whatever, I'd go Electron, at least to
start. Only if I was building video editing software, or a music DAW or
something, then possibly QT.

~~~
sickcodebruh
This is great advice and I really appreciate it.

I work on a piece of fitness equipment. At the moment, our entire UI is built
with TypeScript + React and it's been great: predictable, flexible, easy, and
sooo fast to build and deploy. When we were still figuring out how to define
our core product, this was crucial (especially the development speed) because
I was working as a solo developer, responsible for quite a few environments,
apps, aspects of the product, etc,... Now that things are more well-defined
and we have actual customers, I'm thinking less about how many deploys I can
do in a week and more about performance, stability, and the experience of
using the product. As long as we're stuck in the browser, I worry about some
of the compromises we'll have to make in all of those areas. We already have
some C++ in the stack, so it wouldn't be _completely_ alien, though I'm sure
it would still be _mostly_ alien.

All that said, this is still a long way off. I can still go a long way with
what we've got and I have far too many concerns that matter more to the
product than this. I'm really just starting to think through options so I'm
well-informed when the day comes that this does matter enough to actually
start planning a change.

Again, I really appreciate the advice!

~~~
sonnyblarney
Sounds cool. If you have more questions just ping me tadhman at gmail dot com
, happy to help.

------
sevensor
Despite the focus on QML, the Widgets are very easy to work with -- mature,
well thought out, cross-platform. I highly recommend PyQt for desktop
application development.

------
dang
Discussed in 2016:
[https://news.ycombinator.com/item?id=10940484](https://news.ycombinator.com/item?id=10940484)

------
bgorman
I don't know Qt, but I have a cursory understanding of the DOM, to the point
that I can make fully featured "SPA" applications from scratch. Most of my
background has been in systems programming. Would learning QT enable me to
make applications faster? I have only been exposed to UI programming and
through React via Clojurescript and ReasonML and Angular 6/AngularJS

~~~
beisner
From my (admittedly limited) experience with Qt, it’s an extremely powerful
framework with a somewhat-steep learning curve. Dead-simple apps are dead-
simple, but there’s a lot of Qt-specific stuff (I.e. QML, control paradigm,
extensive libraries, etc.) that you need to learn in order to get the full
value out of it. That said, it’s still a great cross-platform option, and the
fact that it has bindings in most popular languages and is extremely
performant (if you write it properly....) means that it’s probably worthwhile
if you need to make a desktop application.

------
rms25
I really like QML but the licensing is kinda tough for hobbyists if you wanna
do stuff outside of their opensource license. They used to have a cheaper
license

------
TheCabin
Maybe I should read the book, but somebody probably knows: Is there a set a
default widgets when using QML?

~~~
iBelieve
Yes - QtQuick Controls 2. It is discussed in the book at
[https://qmlbook.github.io/ch06-controls/controls.html](https://qmlbook.github.io/ch06-controls/controls.html)
and has official documentation at [https://doc.qt.io/qt-5/qtquickcontrols-
index.html](https://doc.qt.io/qt-5/qtquickcontrols-index.html)

------
ausjke
I'm debating between Pyside2 vs Electron these days, the latter will need some
memory for sure, but I don't need learn the QT apis at least

------
sjvpv
You mean QML? It's weird to see all of the C++ API reduced to a chapter. I've
used Qt for years and QWidgets from C++ is all I've used.

~~~
hellofunk
QWidgets are not under active development, and the future is QML. QWidgets
will likely only receive maintenance fixes going forward. Time to join the
future!

~~~
Longhanks
According to the 2019 roadmap, QWidgets is very much not dead and will get new
widgets this year: [https://blog.qt.io/blog/2019/02/22/qt-
roadmap-2019/](https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/)

My personal opinion of QML is also contradictional: QML on the desktop to me
just feels like a glorified Electron, resizing windows is choppy, controls
feel slightly "off", the "single page" approach just feels like it misses the
platform's defining features (dialogs and multiple windows). Best example is
KDE Discover. But I'd like to be proven wrong, I'd love to hear of QML desktop
software that is genuinely high quality, but I haven't heard of any.

~~~
pfranz
Maybe they've done an about face? I was at a Qt panel a few years ago and they
described QtWidgets as "feature complete" (i.e. not deprecated, but no longer
developed). I'm not sure they knew their audience very well. This was a
computer graphics conference, which has a lot of Python2 deeply integrated to
this day (Python3 is a 2020 goal!). Most of the Qt written is simple windows
where people type in values and move sliders. They seemed very surprised when
nobody cared or had even tried QML.

I gather QML was a push for mobile (which is in line with your criticisms)
where QtWidgets wouldn't work at all. It happens to coincide with Electron
bringing the mobile UI and web platform back to the desktop.

Funny thing, a lot of the 3d apps themselves (Nuke, Maya, Houdini) have very
custom UIs and have all ported to Qt. But this transitioned happened just
before Qt5 so I'm pretty sure it's all heavily modified QtWidgets where QML
might have been simpler to implement. However, any performance issues or
drawing glitches might have been a dealbreaker. That's so important that these
companies actually grouped together and forked Qt 5.6.1[1] with their own
backported bug fixes and critical changes. Thankfully they've been working
with The Qt Company to integrate them into mainline.

[1] [https://github.com/autodesk-forks/qtbase/tree/adsk-
contrib/v...](https://github.com/autodesk-forks/qtbase/tree/adsk-
contrib/vfx/5.6.1)

~~~
toyg
_> a push for mobile [...] where QtWidgets wouldn’t work at all_

Er, they actually worked fine on Maemo/Meego. I think even Android was
supported at some point. But it has never been “cool”, and Nokia were
desperate for getting cool.

QML was an attempt at doing what Electron has done, but starting _from the
other end_ (i.e. desktop -> web, rather than the other way around). It was
aimed squarely at “cool web people” trying to build desktop and mobile apps. I
believe it was also supposed to be married with some integrated cloud service
(where rendering a QML-based interface in-browser was obviously going to be
much easier than reimplementing QtWidgets), but I had no interest in that sort
of thing at the time, and I don’t know the current situation.

~~~
viraptor
> Er, they actually worked fine on Maemo/Meego.

Maemo was basically a full Linux though. It was closer to desktop squeezed
into a mobile screen than a mobile platform, so lots of things could be
compiled and "just work".

~~~
toyg
At the time, Nokia had even ported Qt to Symbian, which is a much more limited
platform than iOs or Android. I don’t think there is any real impediment to
using QtWidgets on mobile platforms.

Edit: to clarify, I mean the original Qt C++ toolkit, not the Python bindings
(pyqt/pyside); the bindings only ever worked on Maemo, if i remember
correctly.

~~~
pjmlp
Kind of.

First they had to create PIPS, a POSIX environment for Symbian, because
Symbian wasn't POSIX and the native language was a C++ dialect known as just
Symbian C++.

Secondly, the Qt based apps weren't pure Qt, you needed to have a couple of
_#ifdef_ s sprinkled around, calling Symbian APIs directly, even for a plain
hello world.

