Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
ChaosKit
Libraries and tools to generate pictures with iterative function systems or Fractal Flames.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Nuitka
Nuitka is a Python compiler written in Python. It's fully compatible with Python 2.6, 2.7, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, and 3.11. You feed it your Python app, it does a lot of clever things, and spits out an executable or extension module.
It really confuses me how anyone would have anything good to say about QML. Qt taking that direction just seems like a panicked decision to try and compete with Electron when they should really be doing the exact opposite.
My experience with QML/Quick is that while you get a little JavaScript runtime and a slightly less obtuse way of defining "widgets" and application layouts than the original Qt "forms", there are some clear drawbacks that make it a near non-starter for anything I've thought about using it for.
Right out of the box, you have to use QML, which is a weird hybrid of language/markup paradigms, and it's a proprietary language. What designer knows QML? Probably f$#%& zero. Electron wins right out of the gate because what designers don't know at least something about HTML and CSS? Sure, if QML was that groundbreaking then maybe people would learn it, but it's owned by a company and it brings nothing new to the table that HTML and CSS can't do better.
The solution to most things in QML is to write JavaScript. I've been a JavaScript engineer for most of my career, but when you're writing a Qt application then the obvious place to do anything useful or complex is in the host language of C++ or Python. So what if you want to tie behavior between your QML widget and a C++ library you either wrote yourself or have imported from a vendor? Well, you can kinda sorta do that, but it's hard to explain here; let's just say that tying a widget to C++ code is extremely clumsy, and good luck calling a function on a QML widget class because you just can't simply do that.
For instance, Qt provides a WebView widget, which was exactly what I needed recently. Uh oh, the decided to make it a QML widget only, rather that do the obvious thing of exposing it as a C++ class and providing a QML widget that wraps around it. Why did they do this? I guess it's because in the long term they think that they'll move away from classic widgets entirely. In any case, I wanted to call the `runJavaScript` method on the widget class without having to jump through hoops in QML. The only way to make that happen was to hack the build process to expose private methods.
But I realized that, at that point, there was no longer any point in using QML if I was going to have to use some neat tricks in C++.
So in just a day, I wrote a classic widget that implements the same WebView used in the QML version, just without any of the QML crap.
https://github.com/Ravenstine/qt-web-view-widget
And yeah, Qt does provide some form of a WebView in as a classic widget but, guess what, it involves bundling a browser runtime rather than using the browser engine of the host OS. Makes sense if you need more of the browser APIs exposed, but if all you want to do is show some simple things on a webpage and call JS from C++, then going through the effort of compiling Qt with support for that browser engine is overkill.
Overall, I don't mind most things about Qt. Despite how overcomplicated some of it is, it does what I want, which is to allow me to write native desktop apps without needing to invest much of my knowledge in OS-specifics. I like that I can use their Bluetooth library and, besides some quirks with how macOS handles device identifiers, I can compile it on other platforms and it will work for the most part.
I wish they'd abandon QML and just focus on making the experience of writing completely native apps better.
for the python environment I use poetry which I think works well (https://python-poetry.org/). As for the licensing (and someone correct me if this is wrong), you have the option to go with PyQt which is GPL licensed and will require you to open source your code, if you go with PySide which is LGPL licensed you do not (unless you make modifications to the Qt code itself which I suppose you're not). So the latter is the better option if you just want to distribute an app.
You don't need to use Qml at all and can use QtWidgets instead which is just their traditional toolkit, or you can combine both. I tried Qml for parts of the UI and it's fairly straight forward.
I think QtCreator supports python now so if you want a complete IDE with graphical tools that works well, I just used my normal editor.
I'm curious, any in particular you'd suggest? I'd definitely give it a shot if it blows Dart out of the water!
[1]: https://dart.dev/null-safety
[2]: https://pub.dev/
I'm not the parent, but I did something similar. It's an editor for fractal flames where the UI is done in QML and rendering and generation is done in C++ and OpenGL. https://github.com/chaoskit/chaoskit
I liked that QML allowed me to iterate quickly on the UI. It was really quick to just compose a bunch of components together and have something working. I also enjoyed the integration with the C++ side. Overall I found QML pretty solid. If I'd build a desktop app again, I'd definitely consider it.
For audio DSP in a Qt app I have good success with using a lock-free queue (e.g. https://github.com/cameron314/readerwriterqueue) to communicate from / to the UI threads. Code more-or-less looks like
connect(model, &ModelObject::somethingChanged, [=] {
and conversely from the engine to the UI thread ; Qt signals do not cut it as emitting them allocate, if only a few bytes. (Doing it naively with std::function doesn't cut it either - I use this instead to store these functions: https://github.com/jcelerier/smallfunction/blob/master/small... ; also, the audio threads feeds back those functions into the main thread after their execution so that any memory owned by the lambda ends up being freed here and not in the audio thread.)
I have the code on GitHub but I haven’t built the code in 4 years so don’t have a screenshot. Like I said, the code was written in about 3 days and QML allowed me to iterate quickly, but the resulting code quality isn’t great (since it was a once off project, built and used in the same week and then never used again, I didn’t clean it up or anything). One key feature was that the LED strip could be connected to a Raspberry Pi and the tool could be run directly on the Pi to control the LEDs directly from the editor, or it could be run on my laptop and simulated.
Anyway, the code is here: https://github.com/danielytics/ledstudio
And the QML specifically is here: https://github.com/danielytics/ledstudio/blob/master/main.qm...
If I were to clean it up, I would at least split the different labels into their own QML files but hey, shortcuts were taken over those few days :)
You can use Nuitka [1] to compile your Python app. It's going to be fairly weak against someone trying to prise out your logic with a decompiler, especially since a lot of Python metadata is left in there (e.g. for generating stack traces), but good enough for most purposes, and unlike some "compilers" it does not have a hidden copy of the original Python buried in it.
If you use standalone mode (not onefile) then all the Qt DLLs and pyd files (which are basically also DLLs) are left separate, which satisfies the LGPL.
This is assuming you're not using QML.