[Rochus]

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.

[Kelteseth]

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.

[Rochus]

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.

[secretsatan]

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

[Kelteseth]

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

[Rochus]

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?

[Kelteseth]

When 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

[Rochus]

I had so many linking issues because of the Qt so on Android that I finally had to statically compile the run some tests at all, and in consequence to replace Qt with something else to avoid royalties. The problem of "DLL hell" (i.e. symbol conflicts between library versions) is well known on Android.