Hacker News Reader

Comment by blinkingled | Hacker News Reader

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?

View on HN

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

Felgo most certainly uses Qt through the commercial license so nothing is LGPL here.

Right. Now imagine it didn't. What then?

you ask them for the LGPL package, they send it to you, you compile ?

The onus is on the person making the app that links against the LGPL library to provide you with the build instruction.

At worse they would give you their main static library and Qt LGPL source code and you just have to relink them and open Xcode to upload it to your iDevice ?

Here is for instance the source code for the telegram app for iOS which is under GPL : https://github.com/TelegramMessenger/Telegram-iOS

there is no difference with... basically every other open source project ? Open the .xcodeproj, build, run.

I am not talking primarily about open source projects, but about closed source projects with LGPL components on app stores. You’d need the proprietary main object from them. Also, requiring that your users have an Apple dev account before they can execute their rights is problematic at best. I am not alone in rejecting Qt on these grounds, in favour of some MIT or similarly licensed alternative.

> I am not talking primarily about open source projects, but about closed source projects with LGPL components on app stores. You’d need the proprietary main object from them.

yes, and as I said if they are not providing them to you they are breaking the LGPL plain and simple. If they break their contract you're in undefined-behaviour land anyways :-)

> Also, requiring that your users have an Apple dev account before they can execute their rights is problematic at best. I am not alone in rejecting Qt on these grounds, in favour of some MIT or similarly licensed alternative.

You don't need a dev account to upload something to your phone since Xcode 7 or 8. Only to put it on the appstore. Prior to that, sure, it was hard to comply with the LGPL.

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.

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.

Reply on news.ycombinator.com