Hacker News Reader

Comment by Alir3z4 | Hacker News Reader

Qt is the reason I started doing desktop cross platform application development several years ago.

Not doing anything new in recent years but Qt is definitely a joy to work with.

From MVC on data management in the widgets, networking, UI handling and tons of customization.

The Qt Creator IDE was the fastest IDE I've worked with and very helpful with Qt Designer integrated.

Dealing with system icons in Linux or i18n, tooling, compilation and building and so many other really complex stuff is pretty damn easy with Qt.

Although I've used Qt/C++ and never the Python binding.

Thanks for all the hard work and amazing people behind it.

View on HN

I recently started a hobby project because I was bored and built an Everything clone with Qt for Python as it doesn't run on linux and I was very surprised how straight forward and performant it is. Despite dealing with a lot of tabular data and Python it seems as fast as C++. Can't claim to understand the magic under the hood but it's very solid.

Can you describe your tooling for Qt with Python development? I've tried to get started a few times but there were some licensing trip ups etc and a lot of different tools on the QT website.

Can you develop a normal (non open source) apps using Qt/Python? For line of business apps users are not supposed to have access to source code etc. Also, do you have to use QML, did you use QML. At first glance that wasn't so appealing.

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.

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 lets you satisfy the LGPL.

[1] https://nuitka.net/

Edit: The above is about deploying your app. For developing your app, feel free to use whatever flavour of the month pip wrapper you want (personally I'm still happy with vanilla virtualenv). You can assemble widgets and layouts into forms either using code or using UI files created in Qt Designer, just as in C++. I've not tried using QML.

What is Everything?

File/folder search for Windows. Super fast, one of my favorite small pieces of software.

https://www.voidtools.com/

So you built an everything clone for Linux? Sounds intriguing.

for realtime applications with multiple threads, e.g. audio DSP, how does qt handle all the complexity with async stuff and messaging between threads without locking all over the place and how does it avoid excessive dynamic memory allocations?

asking because that has been a major problem with JUCE.

No general framework will magically solve this problem, you need to tread carefully around the audio processing thread whatever you're using.

my point is that there is an opportunity for a framework that solves all these problems out of the box.

you could argue that drawing text is not a problem that a framework should solve. yet they do, so there is no reason that a framework cannot solve the typical problems of audio applications and inter thread communication etc.

My own experience is with using QtWidgets in C++ for a multithreaded application that does some disk indexing and database management, the answer is "not that well".

I found that the primitives for threading and message passing between threads didn't work that well for me (both in terms of what they provide and in terms of performance) so I ended up "bypassing" them a bit with my own threading code (that is, still using QThread and QMutex etc. but not using the signals and slots model).

Once I've done that and moved everything off of the main thread, things worked well, so that program is still in QtWidgets with C++ and still in use, but I felt that Qt didn't do a good job of making multithreading easy for me.

That said, I still like continue to use Qt so you can consider this a sort of mild endorsement from me, I guess.

That is what I expected. These frameworks look nice, but were often not created with typical real world scenarios in mind but only work well for very simple data in/out applications where performance doesn't matter.

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, [=] {
      // knead the data structures used for the UI-side data model into something much simpler 
      // used for the audio engine
      audioQueue.push([... data ...] { update the engine with the new data });
    });

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.)

Reply on news.ycombinator.com