Hacker News new | ask | show | jobs
by Rochus 2377 days ago
Yes, exactly. You have my vote and my support in case the Qt framework will be forked based on the LGPL 2 versions and continued from there independently of the Qt Company.

Here some figures: Nokia bought Trolltech and thus the intellectual property of Qt 4 for around 100 million Euros, and then released it to the public under LGPL. Nokia also payed for the development of Qt 4.4 to 5.0, and then "sold" everything to Digia for a piece of bread (about 4 Mio Euros). The contribution rate of Nokia was ~80% according to commit logs; the contribution rate of The Qt Company is at ~40% - and it's mostly on stuff important to them (i.e. which they can sell). So at least 50% are open source contributions by others. This information is all publicly available; you can read it yourself. So the Qt Company massively profited from this and should stop complaining and turning crooked things.

And they have to stop their u-boats, which act anonymously and make opinion.

1 comments

Glad to hear that. How about we change the name to QueTee so that we still can everything starting with a Q and people finally pronouncing the name right? :D
I would rather recommend to stay with the name but add a prefix such as "Free Qt" to demonstrate that it is still and will remain a robust Qt branch doing without incompatible changes and focussing on the essentials. I wouldn't even mind to start with 4.8.6, but also 5.6 is OK (the last LGPL 2.1 version). Work should concentrate on stability, compatibility with relevant platforms and finer grained modularity using a standard build system (such as modern cmake). Rewriting everything just to worship the "modern C++ god" is a no-goal from my point of view.
Nope as a QML developer 5.14 is bare minimum because of the many changes like proper 4k scaling support, Splitview, Table support, way better Android build, usable Qt3d and many quality of life improvements.
Are you aware of Dart and Flutter? I also used Qt on Android and iOS once. Won't do it again. A lot of linking, deployment and licensing issues to use something where by the end of the day I have to take care myself that it meets the platform look and feel. QML/Qt Quick was a nice idea when Nokia and others wanted to establish a common mobile platform based on the Qt framework. Today for scripting/mobile UX focussed developers there are much better options.
We're working on a cross platform mobile app rn and we're using QT because "everyone else in the company is using it". It might be good for desktop, but I've found it to be nothing less than frustrating, it reinvents the wheel for mobile, and doesn't do it very well. It's still missing many features, we still have to keep going back to native views to implement things because QT just can't do certain things. We've lost developers because they want to work with mobile technologies and QT seems like 10 steps back. Swift and Kotlin address many issues of cpp, we don't have access to the wide amount of mobile libraries. We replace things with cpp libraries never compiled for ARM that ends up with incredible amounts of code that would take a few lines in native. Every library we add brings more headaches. And then we have desktop developers diving in and designing everything like it's desktop, button and menus too small, scaling the view to fit different device sizes. ugh
Yes I am aware of the alternatives. Still having used a ton of UI libraries (Unity/Unreal/Godot/C#/QtWidgets/Flutter and web development) I would still choose QML by a landslide. My project ScreenPlay [1] (Cross plattform animated wallpaper and desktop widgets) is written 100% in QML and C++. I use the build in Material Design on desktop which works really nice with fancy animations. At work I develop a cross platform Qt app for desktop and Android tablets. With QtCreator 4.11 they unified the apk creation for all arch and arm versions.

[1] https://gitlab.com/kelteseth/ScreenPlay

Interesting. How did you solve the LGPL licencing issue? Did you have to pay a commercial licence and pay royalties to The Company?

EDIT: ok I see, your project is AGPL. But that just moves the issues to your clients; how do they solve the issue?