Hacker News Reader

Comment by viraptor | Hacker News Reader

What would it provide that Qt + QML don't right now? (if we assume that the crossplatform GUI is the killer feature)

Every time mobile cross-platform is discussed, someone brings up Qt when it's less popular for mobile development than React Native, Flutter, Xamarin, or PhoneGap/Codova. Maybe even less than Ionic, NativeScript, or Appcelerator. Why even bother with such a niche solution? Are there even live cases of mobile apps using Qt?

> Every time mobile cross-platform is discussed, someone brings up Qt

For what it is worth I can't see anyone mentioning mobile and however weird this sounds, for me at least cross platform always implicitly meant across desktop platforms.

Cross platform on mobile never really happened, thanks to Steve Jobs, and I am kind of happy for it so far.

Sure it did, in all these years my only native apps have been on personal projects.

In what concerns work, we use a mix of mobile Web, Xamarin, Cordova/PhoneGap, C++ with native views, depending on the customer requirements.

The article context is Windows and Linux. I'm not sure where "mobile cross-platform is discussed".

But if you want to go to actual cross-platform-beyond-desktop, Qt is still massive on other devices. From cars to TVs to smart fridges.

I'm sure licensing is a big one. It looks like SwiftUI is MIT license and Qt is dual licensed.

I think you are mixing up Swift and SwiftUI.

Swift is a programming language created by Apple, it's been cross-platform for a while but is now going to be officially supported on Windows. Swift is Apache licensed.

SwiftUI is a UI framework created by Apple for the Swift language, it's only available on Apple platforms, and it's proprietary.

Thanks for the correction! I knew of the distinction, but in my haste I was looking at a different repo (and I blanked that the source hasn't been released and licensed).

Swift looks to be Apache licensed. I'm fairly confident SwiftUI wouldn't have a commercial license, which is a major topic with using Qt.

A modern, powerful memory safe language? C++ is hardly a good choice for making casual small GUI apps.

except for the documentation the python (pyside2) bindings seem pretty complete.

Qml supports ES7 so you only really need to touch C++ if you're not making "casual small GUI apps". If you need to draw custom items or do low level networking then yeah you need to use C++ but even then Qt is much friendlier than using the standard libraries.

Here is a Qt C++ example:

    QString str = "/a/b/c/";
    auto parts = str.split('/');

Like Crystal, Go and Rust? (and QML for the basic events handling)

https://en.wikipedia.org/wiki/List_of_language_bindings_for_...

Have you made any non-trivial use of the Qt bindings for those languages? Qt is a big and complex library, and most bindings are incomplete or poorly documented. As far as I know, PyQt is the only Qt binding is the only one that you can really rely on to work now and in the future.

There is PySide2/Qt for Python which are the official Python bindings for Qt by the Qt Company itself and they are close enough to the C++ API(since they are auto-generated) that it's possible to just use the C++ documentation and translate any C++ code into python nearly 1:1 (except things like QString where you can just use Pythons native types).

Not terribly complex, but not trivial either. Yes, there are missing pieces in non-python ones. But given that basics are handled, it's often pretty easy to add the pieces which you need.

Depends, if you are coding C in C++, or making use of idiomatic C++17 (eventually C++20).

Pricing and not being c++

LGPL is free and there are Qt bindings in pretty much all languages now (+ I mentioned QML for that reason).

Bindings are very limited except for maybe python. Using almost any binding you are destined to hit a bunch of roadblocks. Lots of people can’t use lgpl.

Hate to say it, but the sanest thing to do if you need a cross platform UI is use Java. Your other choice is Electron, which is way slower and uses many times as much ram

I wonder whether GraalVM native image will play a bigger role in desktop apps in the future.

Kotlin + TornadoFX + native-image (if it is supported) sounds like a pretty comfortable to use UI stack.

Gluon has been putting a lot of work into native-image + JavaFX for cross platform. Im not sure if it'll catch on though.

It’s the sanest thing to do if you can write proper Java, and actually want to do so.

Reply on news.ycombinator.com