3 ms·
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
by Rochus 7y 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.
- Kelteseth 7y agoGlad 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
- Rochus 7y agoI 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.
- Kelteseth 7y agoNope 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.
- Rochus 7y agoAre 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.
- Kelteseth 7y agoYes 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 https://gitlab.com/kelteseth/ScreenPlay
- Rochus 7y agoInteresting. 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?
- Kelteseth 7y agoWhen distributing qt on android you can simply write an guide on how to decompile the apk, replace the qt .so and compile it again. I haven't done it yet so I'm not 100% sure about this. Also you could simply install ministro for this. https://doc.qt.io/qtcreator/creator-deploying-android.html https://doc.qt.io/qtcreator/creator-deploying-android.html