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.
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 ch@christianjaeger.ch 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 :).
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).
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.
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.
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.
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.
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.
No, but nothing else does either - you'll need to ship runtime environment in any case. And packing JRE is more cross-platform tested than most other solutions.
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.
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?
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.
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)
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.
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.
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.
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.
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.
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].
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.
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.
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.
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.
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 :)
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?
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".
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.
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?
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.
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.
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.
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.
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
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.
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.
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!
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.
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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.
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. :(
