A Book about Qt5
qmlbook.github.io
qmlbook.github.io
Does this come packed with most platforms (Mac, Linux, Windows)?
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/.
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).
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.
There are also Qt bindings for a bunch of other languages, but Python seems to be the best supported after C++
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).
Qt on the other hand is well documented, and reasonably stable over the years.
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 :).
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.
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.
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.
On a related note, does anyone know of a way of creating a "stand-alone binary" or installer for PySide2?
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.
It’s trivial to add pyuic as an external tool in most iDEs anyway.
I'd like to read some examples of that.
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.
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.
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 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.
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.
What you meant to write probably was “PyQt is not free to use in closed-source applications”.
I cannot speak for pyside/“qt for python”, but that project has always lagged behind PyQt, so it’s unlikely to be much better.
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 :)
Seems to be based on user submissions.
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?
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".
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.
When you say many of _their_ customers, who is they? Qt or the people responsible for QML?
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.
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.
Again, I really appreciate the advice!
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.
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.
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...
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.
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".
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.
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).
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).
You can get the latest update on their Meeting C++ 2018 session.
"Recent developments and future outlook of Qt"
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.
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.
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.
Um, not really. The inbuilt Universal style looks pretty good by default.
Does Electron handle those scenarios well?
I'm sure it's a nice book, though.
Basically all the classic QtWidgets and the underneath desktop services.
> 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.