Hacker News new | ask | show | jobs
by blinkingled 2395 days ago
I always wonder why Qt5+/Qml/QtQuick have not taken the XP desktop development by storm. QML is JS like, there's an IDE and KDE seems to have built lot of good looking desktop software using Kirigami/QtQuick.

It's got to be better than anything Electron for sure.

Anyone know if .NET Core Qt bindings are a technical possibility?

7 comments

Two replies mention licensing, with two different answers (It's easy, people just don't understand! It's hard, people just don't understand!). Personally, I've tried a couple of times to read the license information on the Qt site and sort out how the licensing really works. I still only have a rough understanding. It seems like information on the Qt site is intentionally vague so you'll be more inclined to buy a commercial license just to feel "safe" using it. Unfortunately, any commercial projects I work on can't justify the commercial license price.

Anyway, the point is, people may not want to use Qt without being absolutely certain about how the licensing works and they (like me) probably don't have the time to try to understand the poorly organized information on the Qt site.

> Personally, I've tried a couple of times to read the license information on the Qt site and sort out how the licensing really works.

You could just go to the repo and check the licenses there :

https://github.com/qt/qtbase

> I always wonder why Qt5+/Qml/QtQuick have not taken the XP desktop development by storm.

If I had to guess, it's because people are misinformed about the pricing and features. I regularly see people who assume that you either have to pay a large per-developer fee, or completely open source your application, even though Qt is licensed under the LGPL, so you're fine as long as you don't statically link it or depend on secret modifications to Qt for your application. A lot of people also assume it only supports C++ and dismiss it outright.

LGPL is problematic for App Store, since the user should be able to relink the app with a newer version [of QT] if they wanted to.
They can relink. The object files for relinking aren't required to go through App Store.

Static/dynamic linking isn't a problem.

Interesting. If I install this [0] app, how can I relink it against my patched QT5?

0: https://apps.apple.com/us/app/qt-5-showcases-by-v-play-apps/...

Normally you ask them for the object files, but those specific guys are middleware developers so they provide QtCreator configured to build with their library (to get a different Qt version, select a different Qt Kit in QtCreator settings).

Additionally, the nature of the library is that it's probably a plugin that's loaded by a regular Qt application, as a result you've got their classes available in the QML scripts. It isn't very intrusive on the practical level.

They don't say what license they use though.

Felgo most certainly uses Qt through the commercial license so nothing is LGPL here.
Right. Now imagine it didn't. What then?
A .Net Core Qt Quick binding is not only possible, but very real: https://github.com/qmlnet/qmlnet

I think most KDE apps are neither written using Kirigami nor Qt Quick however, but plain old Qt Widgets (maybe I'm misinformed, but Kirigami doesn't look much like it's customizable by the desktop environment, which is something I love about KDE apps).

Wow, that looks neat and the sample worked as expected including picking up the KDE breeze theme!
My bet is the licensing stuff which can make it difficult/expensive to make proprietary apps with it. (In practice, I know the picture is a bit complicated.)

Also, personally, while QML probably is the nicest OOP/bindings style UI framework I've seen, it's still not as nice as any of the reactive ones (i.e. React, Vue, Angular2, Flutter, etc…).

It's JS, but not webdev JS, which means they can't really transfer much of the DOM knowledge/tooling.
Because .NET, Delphi or C++ Builder are better options if you are paying anyway, and only focusing on Windows.
.NET Qt bindings are possible; the question is how much effort it would take.

There are already GTK bindings for Mono through Gtk#. Those should be usable under .NET Core.