A Book about Qt5(qmlbook.github.io)
qmlbook.github.io
A Book about Qt5
https://qmlbook.github.io/
120 comments
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.
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, https://franz.com/products/packages/.
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, https://franz.com/products/packages/.
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
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).
See for example the price for VA Smalltalk...: $6995 for a new developer license.
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).
I'll mention an earlier comment of mine: https://news.ycombinator.com/item?id=18045890 (a Scheme interpreter running in C++ land, to communicate with via s-expressions (really Scheme code) from 'real' Scheme or Lisp systems. Extending its parser to support Clojure and CL is on my mind, extending the interpreter to run programs written in those languages (e.g. '(defun square (x) (* x x)) instead of '(define (square x) (* x x))) is of course also a possibility if deemed useful enough.)
My work was interrupted because my employer decided to scrap the project this was planned for. I've got permission to release it as open source, which I'll do ASAP (I'm in the middle of cleaning it up a bit). Incidentally my position was made redundant at the same time, so I'm currently looking for new work, most likely I won't have too much time to work on that in the near future, but I'll try to continue working it on the side and will be happy to help where I can. Send me mail to [email protected] if you'd like to be notified once it's up.
My work was interrupted because my employer decided to scrap the project this was planned for. I've got permission to release it as open source, which I'll do ASAP (I'm in the middle of cleaning it up a bit). Incidentally my position was made redundant at the same time, so I'm currently looking for new work, most likely I won't have too much time to work on that in the near future, but I'll try to continue working it on the side and will be happy to help where I can. Send me mail to [email protected] if you'd like to be notified once it's up.
> I could use Racket and it's GUI library, but Racket is marketed as a language for creating languages, so I'll skip that.
Why? Racket is very far from only being a language research platform, it's also a very good general purpose programming languages, and its GUI framework is quite easy to use. I would give it a try if I were you :).
Why? Racket is very far from only being a language research platform, it's also a very good general purpose programming languages, and its GUI framework is quite easy to use. I would give it a try if I were you :).
Another option would be GTK. It is quite portable and while I haven't checked out the GTK libraries for Common Lisp, but as GTK is a pure C-based API, binding to it from other languages is very easy, so good bindings should be available. Personally, I have been using GTK3 via Go on Linux/Mac.
And for Common Lisp, there is of course LTk, it is extremely portable, but you have to live with the Tk UI toolkit (which got a pretty native look in the meantime).
And for Common Lisp, there is of course LTk, it is extremely portable, but you have to live with the Tk UI toolkit (which got a pretty native look in the meantime).
Gtk itself is poorly documented for non-trivial examples, and doesn't seem all that stable across the years.
Qt on the other hand is well documented, and reasonably stable over the years.
Qt on the other hand is well documented, and reasonably stable over the years.
Why not use Java 9 instead of 8? This could give your desktop app a smaller footprint (using the new modular jdk feature), so your app could start up faster.
I read somewhere that java 9 is not supporting JavaFX, I guess I could just add javafx as a dependency and it should work fine in java 9 also.
No it was removed only in JDK 11.
Here's an example of a modular JDK 9 + JavaFX 9 app: https://carlfx.wordpress.com/2016/04/26/a-javafx-helloworld-...
Oh, I missed that. What is the officially sanctioned way to build GUI in Java 11 then? Swing?
They have decided to make it in a standalone package so it can evolve independently. Like xamarin is not part of .net
Its not about being supported or not. It's just an external. it's not up-to-date with java 11 https://openjfx.io/
You can also use clojure with it if you want a lisp dialect.
Its not about being supported or not. It's just an external. it's not up-to-date with java 11 https://openjfx.io/
You can also use clojure with it if you want a lisp dialect.
If you're using Java anyways, why not clojure? I've written both clojure an common lisp, and even though the immutable datastructures take some getting used to if you're from CL or Java, they're awesome, fast and make programming so much more fun.
I was thinking about clojure. I think only choice I have is to use 'seesaw'(wrapper for swing). I haven't seen any promising wrappers for javafx yet.
You should check out cljfx[0]! It's a re-frame-like wrapper for javafx, and it looks very well thought out. It's very well documented and the maintainer is very responsive if you need help.
[0]https://github.com/cljfx/cljfx
[0]https://github.com/cljfx/cljfx
Hm I'm in the exact situation and I'm total beginner on desktop apps. I've been looking into Flutter for desktop but it isn't stable yet. If you ever come to a conclusion would you mind to share it? Thanks.
JavaFX is a great choice for beginners. Whatever app you make, anybody can run so long as the have the JRE installed.
Isn't it heavy and slow though? At least that's what I hear. I use android studio in a beefy macbook pro from time to time and it's slow as hell.
Jetbrains uses Swing not JavaFX from my knowledge. And yes, the performance can get slow for a Java app on the scale of Android studio but that shouldn't be of concern to a beginner.
LispWorks CAPI is very good. It's a shame it's proprietary and not cheap.
Why the focus on niche languages / frameworks? Why not make your life easy and use Qt (C++) or Electron (JS)?
I don't really know C++ and I'm sick of JS. But I will take a look into Qt.
You can also use Qt from Python using PyQt or PySide, which is officially supported as of recently - https://www.qt.io/qt-for-python
There are also Qt bindings for a bunch of other languages, but Python seems to be the best supported after C++
There are also Qt bindings for a bunch of other languages, but Python seems to be the best supported after C++
How about Xamarin?
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.
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.
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.
PySide2 makes this way easier. I recently setup a PySide2 Project in PyCharm with the integrated package-management and it was a breeze (I guess the official support helps a lot as opposed to PySide[1]). First tried several other graphical libraries and was getting nowhere, but was happy that the Qt integration was relatively painless.
On a related note, does anyone know of a way of creating a "stand-alone binary" or installer for PySide2?
On a related note, does anyone know of a way of creating a "stand-alone binary" or installer for PySide2?
PyInstaller and cx_freeze both work with PyQt, afaik, so they probably work with pyside too.
There is also some other project (fsmb? Something like that) that is focused towards packaging pyqt apps, but it requires you to adopt its framework.
There is also some other project (fsmb? Something like that) that is focused towards packaging pyqt apps, but it requires you to adopt its framework.
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.
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.
They are now investing into Python as official supported language.
https://www.qt.io/qt-for-python
https://www.qt.io/qt-for-python
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.
WxWidgets is now available & stable(!) for Py3 and available on PyPI for easy installation & distribution. Moreso, the dev pipeline has been streamlined and they are now able to follow upstream much more closely! Maybe this is sth for you.
Regarding Go / Browser interaction sI've stumbled on two libs : https://github.com/zserge/lorca to integrate chrome as a UI (smaller than electron apparently) and https://github.com/zserge/webview (not tested myself and the second one is rewritten currently)
I just run Go binaries and talk to them using gRPC. As a real world example on how to do that, here's my app: https://getaether.net and here's the source code: https://github.com/nehbit/aether.
> the differences between what QtDesigner showed and the actual output
I'd like to read some examples of that.
I'd like to read some examples of that.
Yeah I rather not thinker with it again, maybe someone else has some idea why that happens; I remember being something about the text looking centered on the editor then not so on the generated bindings.
Could you elaborate a bit on the compile times? Python is an interpreted language, so am surprised to see that as a pain point.
I don't remember the specifics, I remember that after designing the UI files on QtDesigner you had to compile some files that python consumes, some sort of bindings to the interface you created.
[deleted]
You never had to do that. You can load Qt Designer XML files at runtime with neglible performance impact.
I still like to use pyuic so that the IDE will pick up the generated file and suggest widget names while you’re editing the subclass. Otherwise you’re a bit blind.
It’s trivial to add pyuic as an external tool in most iDEs anyway.
It’s trivial to add pyuic as an external tool in most iDEs anyway.
Good point, though I personally don't work through self.ui but rather prefer loading into the class itself. Then I just put type annotations of the widgets in the class.
Not to mention the expensive licenses for both pyqt and qt itself.
PyQt5 is GPL licensed. Not expensive, but perhaps not suitable for your closed source project. There is also a commercial license available, probably that is expensive.
PySide2 is LGPL licensed, so more likely to be suitable for you, since it can be used without having to provide the source of your application.
Both libraries serve the same purpose of providing Qt5 bindings for Python in slightly different ways. PySide2 has become officially supported by Qt recently, and has generally been the preferred option for closed source development due to the licensing.
PySide2 is LGPL licensed, so more likely to be suitable for you, since it can be used without having to provide the source of your application.
Both libraries serve the same purpose of providing Qt5 bindings for Python in slightly different ways. PySide2 has become officially supported by Qt recently, and has generally been the preferred option for closed source development due to the licensing.
Qt is licensed under the LGPL. Same goes for PySide.
Yes, I'm talking about use of qt in a closed-source commercial product.
You can ship a closed-source product with LGPL licensed libraries like PySide/PyQt as long as you respect the license (most difficult part to comply with is relinkability by the user if you're shipping with static libs) [1].
[1] - https://www.qt.io/faq/#_Toc_3_7
[1] - https://www.qt.io/faq/#_Toc_3_7
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
PS: I'm the author.
I also went to mention that you can now use .NET/C# with QML as well.
https://github.com/qmlnet/qmlnet
PS: I'm the author.
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?
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?
I haven't used Qt4, but I haven't had issue with segfaults and pure C++/QML integration.
When it comes to the .NET integration, you don't have to worry about the .NET GC or the JavaScript GC. There are extensive unit tests to ensure that the two garbage collectors work together.
I would actually say it's impossible to make QmlNet segfault.
When it comes to the .NET integration, you don't have to worry about the .NET GC or the JavaScript GC. There are extensive unit tests to ensure that the two garbage collectors work together.
I would actually say it's impossible to make QmlNet segfault.
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.
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.
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”.
What you meant to write probably was “PyQt is not free to use in closed-source applications”.
My company uses Qt5 via Python fairly extensively. While it's great almost all the time, we've definitely encountered a few weird issues with segfaults, especially on Windows. Some our fault, some due to weird Qt/graphics driver interactions.
Recent PyQt segfaults a bit less than it used to do in Qt4-times. I believe Riverbank made some efforts to avoid the most common problems with object lifecycle. This said, underneath C++ and CPython have very different ideas about lifecycle, and Qt is very complex, so the occasional issue has to be expected.
I cannot speak for pyside/“qt for python”, but that project has always lagged behind PyQt, so it’s unlikely to be much better.
I cannot speak for pyside/“qt for python”, but that project has always lagged behind PyQt, so it’s unlikely to be much better.
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
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 :)
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 :)
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?
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?
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".
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".
The Qt Showroom may be useful as well:
https://showroom.qt.io
Seems to be based on user submissions.
https://showroom.qt.io
Seems to be based on user submissions.
Another good example is Blizzard's Battle.net app https://www.blizzard.com/en-us/apps/battle.net/desktop
No screenshot on mobile. Where is it?
Oops, I'll check whats up with that. Meanwhile https://www.sostronk.com/assets/tilt-ca31719ca134cbaf.png
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.
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?
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.
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.
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?
When you say many of _their_ customers, who is they? Qt or the people responsible for QML?
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.
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.
Perfect, thank you. More and more, Qt sounds like the right fit for the product I work on.
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.
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.
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!
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!
Sounds cool. If you have more questions just ping me tadhman at gmail dot com , happy to help.
Qt is nice but takes some effort to make it do what you want it to do, just like any other c++ project. Once you get the hang of it though it can do just about anything, on any platform. At my previous job we had deployed a single code base QML ui interface across mac/windows/linux/android/ios. The mere fact you can do that and have it not look like junk everywhere is pretty cool.
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.
Discussed in 2016: https://news.ycombinator.com/item?id=10940484
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
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.
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
Maybe I should read the book, but somebody probably knows: Is there a set a default widgets when using QML?
Yes - QtQuick Controls 2. It is discussed in the book at https://qmlbook.github.io/ch06-controls/controls.html and has official documentation at https://doc.qt.io/qt-5/qtquickcontrols-index.html
There is qt quick controls. And some third party library like kirigami from kde.
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
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.
Indeed. I was bemused by the first sentence in the section explaining the architecture of Qt:
> Qt Quick is the umbrella term for the user interface technology used in Qt 5.
It is not "the" user interface technology in Qt, but one of them. This is a very confusing way to start a book that is supposed to be an introduction to Qt.
> Qt Quick is the umbrella term for the user interface technology used in Qt 5.
It is not "the" user interface technology in Qt, but one of them. This is a very confusing way to start a book that is supposed to be an introduction to Qt.
The url and logo say “qmlbook”, so I guess it was originally meant to focus on QML only.
This (and WebEngine) is why we switched to Gtk.
I'm sure it's a nice book, though.
I'm sure it's a nice book, though.
Could you elaborate here please? I'm trying to learn qt at the moment.
I believe he means that he switched to GTK because Qt is moving away from traditional desktop widgets (in favour of QML / QtQuick) and he didn’t want to go that way.
Hm that's a bummer. It sounds like it's taking the Electron path then? Because that's exactly what I was trying to avoid.
The code is also compiled to native code, but it's written declaratively. It's not for everyone, but it's not the same as Electron. Even still you have the option to use the traditional imperative API.
I'm sure one cause is that QtWebEngine is a steaming garbage fire, with a far more limited API than the old WebKit based system, and many more bugs (not that the Qt4 WebKit support was a shining example) -- especially if you attempt to "deploy" (package) an app using it on MacOS.
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!
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/
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.
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.
As someone who recently worked with QML a lot, resizing is definitely a pain point. I have yet to see a great pattern for handling this, as there's definitely no one-size-fits-all within QML.
For multiple pages, you can create multiple Windows / ApplicationWindows for one app. It definitely could have more support though - as for now you have to control these via C++ Qt code.
For multiple pages, you can create multiple Windows / ApplicationWindows for one app. It definitely could have more support though - as for now you have to control these via C++ Qt code.
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...
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...
Right now they are focused on IoT and car infotainment systems, as those are the customers willing to pay for Qt licenses.
You can get the latest update on their Meeting C++ 2018 session.
"Recent developments and future outlook of Qt"
https://youtu.be/PqLkBtA7DQc
You can get the latest update on their Meeting C++ 2018 session.
"Recent developments and future outlook of Qt"
https://youtu.be/PqLkBtA7DQc
> 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.
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.
> Er, they actually worked fine on Maemo/Meego.
Long before then and before Nokia even, back when smartphones were called PDA's, the iphone wasn't released and when maemo was GTK based, there was a QtWidgets based environment called qtopia (https://en.wikipedia.org/wiki/Qt_Extended).
Long before then and before Nokia even, back when smartphones were called PDA's, the iphone wasn't released and when maemo was GTK based, there was a QtWidgets based environment called qtopia (https://en.wikipedia.org/wiki/Qt_Extended).
If you've ever tried to do fancy animations in C++ using QSceneView, it's obvious why they created QML. It is painful to manually maintain all the relationships and transient states needed for an interactive animated UI. QML makes that simple and easy.
My only real problem with QML is that things can get really hairy really fast. QML does a great job of abstracting over it, but the complexity is all still there underneath. When something goes wrong, you end up debugging a tangeled mess of implicit behaviours, many of which were probably unintentional and unnoticed by anyone (including the original author that created them).
My only real problem with QML is that things can get really hairy really fast. QML does a great job of abstracting over it, but the complexity is all still there underneath. When something goes wrong, you end up debugging a tangeled mess of implicit behaviours, many of which were probably unintentional and unnoticed by anyone (including the original author that created them).
> 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".
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".
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.
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.
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 #ifdefs sprinkled around, calling Symbian APIs directly, even for a plain hello world.
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 #ifdefs sprinkled around, calling Symbian APIs directly, even for a plain hello world.
> This was a computer graphics conference, which has a lot of Python2 deeply integrated to this day (Python3 is a 2020 goal!).
Were you at SIGGRAPH? One of these days I’m going to make it to the conference and attend a meeting on the Platform. I was a little disappointed that 3.6 got offset to a tech preview with 2020 as the goal, but it’ll be worth it if we can get everyone using mainline Qt 5.12 AND official 5.12 PySide (Qt for Python...).
The future is bright for the VFX Platform! Just not with QML, Widgets are here to stay for these kinds of apps.
Were you at SIGGRAPH? One of these days I’m going to make it to the conference and attend a meeting on the Platform. I was a little disappointed that 3.6 got offset to a tech preview with 2020 as the goal, but it’ll be worth it if we can get everyone using mainline Qt 5.12 AND official 5.12 PySide (Qt for Python...).
The future is bright for the VFX Platform! Just not with QML, Widgets are here to stay for these kinds of apps.
Yep. The talk I had attended was specifically about Qt. Most of the VFX reference platform discussion happens on the mailing list before Siggraph since they try to present next year's platform at the conference giving companies enough time to implement them by the new calendar year. But it is really cool to have people sit in a room together and share the problems/solutions only a few people at every company have to deal with.
Python3 has been a topic brought up for many years and pushed off for other things. I'm kind of surprised how much progress they've made in moving these companies forward and keeping them roughly in step.
Python3 has been a topic brought up for many years and pushed off for other things. I'm kind of surprised how much progress they've made in moving these companies forward and keeping them roughly in step.
I remember the reaction on the list when Python 3 was initially added and set (before Qt 5.12 was added). Felt like a universal sigh of relief. Then the discussion about which minor version to choose (3.7 was due in a few months at the time), but the general consensus was “just get us on 3, doesn’t matter which” so 3.6 it is.
My only concern right now is Autodesk potentially dragging their feet on this, which I really hope they don’t do. But they’ve also got a lot of other things on their plate.
A bit grumpy that their M2019 release is still using Qt 5.6.1 even with their several month delay that went into 2019, but maybe they’ll do something radical and upgrade it through. I remember Wayne and others being happy about the push to GCC 6.3 and finally being able to use C++14.
My only concern right now is Autodesk potentially dragging their feet on this, which I really hope they don’t do. But they’ve also got a lot of other things on their plate.
A bit grumpy that their M2019 release is still using Qt 5.6.1 even with their several month delay that went into 2019, but maybe they’ll do something radical and upgrade it through. I remember Wayne and others being happy about the push to GCC 6.3 and finally being able to use C++14.
I think that is a consequence of the protests regarding QWidgets stagnation, however given the focus on Qt Design Studio, Qt 3D Studio, devices and car infotainment systems, I am not sure how what those updates will actually be like.
QML is a solution for a specific use case, it's not "the" future.
QML also misses out on its widget set. It's too limited. There need to be a lot more widgets that work out of the box.
Also excessive styling of elements seems to be needed. That's exactly something a developer can't do. Nice looking QWidgets were and are a simple way to empower a developer to create a useable UX quickly.
Also there should be a C++-only API for creating Qt Quick widgets.
It might be a good idea to leverage the c++ knowledge of your userbase, if your core userbase are c++ developers.
> Also excessive styling of elements seems to be needed
Um, not really. The inbuilt Universal style looks pretty good by default.
Um, not really. The inbuilt Universal style looks pretty good by default.
Time to join the future and rewrite the huge application I work on? I sure hope not.
QML is just a teaser. Once you taste it you'll want the real thing and you'll move to Electron.
I had the opposite experience. Each to their own.
The browser-application-pretending-to-be-a-desktop-application things I've seen don't handle multiple windows correctly, and most of them have problems with multi-key custom keyboard+mouse actions. :(
Does Electron handle those scenarios well?
Does Electron handle those scenarios well?