Hacker News Reader

Comment by simion314 | Hacker News Reader

>Even QT, a C++ standard is quite complicated

What is complicated about Qt ? You have widgets and events(called signals) , you have clear way to do layouts and powerful ways to extend things. My only complaint is not about the API but is abut C++, when I was working with Qt4 there were not good official or unofficial but stable bindings to memory managed languages.

So personally for a quick side project I don't want to use c++, since is a side project some ugly and slow Electron app will be good enough and if I were on Windows I will probably do a C# Windows form app , or a Java Swing app.

View on HN

Nowadays that isn't the way to use Qt.

You would use QML, which is quite similar to JavaScript, alongside the quite nice designer tooling, while implementing in C++ the code that needs high performance.

Additionally QML also gets compiled to native code anyway.

Although on Windows only apps, I would also use C#.

Java Swing is nice (yep I own the Filthy Rich Clients book), however it is basically stagnant since Java 8, minus bug fixes, HiDPI and Metal backend.

The UI part is not the issue, if you decide to use Qt you still need to do your "business" logic in c++ , then eventually you get some memory leak and have to setup tools to investigate what is the issue.

What would be a great feature for Qt is to have a way to make the GUI with QML but implement your actual work in C#,python,Java. So you would need a way to connect the GUI with data types and functions from this languages.

I remember Qt company tried at one point to offer Java,C#, Python official bindings but that effort failed, is probably hard.

Maybe an alternative to electron would be a JVM based modern GUI framework, something maybe inspired from the best parts of WPF, MXML and QML. And I am thinking JVM because you have access to Java's big standard library to do desktop like things like file,network IO and also have access to the native OS if needed.

You can do the business logic in QML, that is the best practice nowadays. That is why it is a full blown language based on JavaScript.

Or do little helper classes that you than use from QML, just like those Python libraries that are mostly native code.

Qt also has official Python bindings nowadays, even though the others were dropped, due to lack of interest.

Don't forget automatic memory management can also have other kinds of leaks, and use similar tooling, to track down where references are wrongly being kept alive, e.g. Forms/WPF event handlers.

Once the project moves to push bindings I think you can see it’s admitting the language they picked is no longer fit for purpose :). Go comes to the rescue here and Fyne is idiomatic Go so learning it is trivial!

Python and machine learning libraries....

You have bindings in rust or python or other languages

There were always been bindings, but at the time I was working with Qt the quality was bad, if I were to start a project I don't want to use some automatic generated binding or some one man side project binding, I don't have time to spend in debugging bugs outside my code.

Except of Python are there other bindings you would bet your precious time on? Foe example I had a few hours side project, I needed a simple GUI to let the user slect soem folder and files, then the code logic would do the IO , do some transformetion and report to the user. Would I spend more time messing around with the bindings instead of writing the code ?

I know my example would be a perfect use for CLI but the target user was a Windows person that just REFUSED to accept the concept that they are competent person and could use a CLI app and paste a folder path in.

If I were to do desktop on the JVM I’d probably use Kotlin’s desktop compose. But I’d probably also weigh out .NET Maui/Avalonia in that case too.

Don't forget JavaFX. It's pretty good, many features, mature and stable.

Plenty of people still use QWidgets.

For 99% who want to ship something and are not hipsters, QWidgets is enough.

Personally I don't even build QML

Yeah, when targeting desktop only workloads, given that they have hardly been updated for anything else, and it is actually one of the Qt 6 roadmap items to improve upon.

Everything about QT is complicated.

Everything in QT is non-trivia especially due to it's use of C++.

Signals themselves are a bit tricky, and frankly a kind bloat, in that they are yet another abstraction that is not actually needed.

Signals, which are related to the event loop and threading, create a bunch of potential issues that can't really raise their ugly heads in JS/Python, and even in a multi-threaded language like Java are a bit easier to deal with.

QML is quite good for a narrow range of things, but if you start to go outside the bounds of what it was intended for it goes of the rails. You still need to know C++ for builds, and, C++ integration doesn't work particularly well.

IDEs do not refactor well in C++, don't pick up as many errors, cmake is weird.

QT has some amazing things (collections) that without, frankly, I don't think I would even use C++, but they all come with hints of weirdness.

QT written today, for a narrow platform, in a single language, hopefully more modern - would be something different.

The paradigm of qt is good, the code is cryptic when you are a beginner. It uses too much concepts that people wouldn't necessarily be used to. If you read the code there would be many lines where you just tell "what is this?".

Reply on news.ycombinator.com