Why don't you fork Qt?

[ghost]

I don't have positive experience with CopperSpice. I don't think they have enough resources to maintain the code base. The library is full of unresolved bugs and the GUI part is lagging behind Qt. They can only add trivial additions like CsVulkan. They can't import code from Qt because Qt is now LGPLv3 and they are stuck with the last LGPLv2.1 code.

I think Rochus Keller's LeanQt is a better approach. You don't have to use your own build system like him, though. The problem with the LeanQt project is Rochus Keller is refusing to update his fork, even for security fixes from the upstream Qt project. His LeanQt project now can't even build with a modern MinGW-w64 compiler.

Btw, what's wrong with becoming a de-bloated Qt?

[RolandHughes]

Btw, what's wrong with becoming a de-bloated Qt?

Many things.

1. Qtc has an "Everybody must buy a license" view of OpenSource. Even some of the stuff KDE uses isn't officially OpenSource per discussions on the mailing list.
2. The malignant tumor of QML is so deeply metastasized one could not rip it out without starting over.

Been a bit since I checked, but as the image shows, at one point not that long ago the Qt bug database was over 30,000 deep. Some of those bugs were old enough to legally drink in America and quite a few were old enough to get a driver's license.

Some of the changes CopperSpice made will have gotten rid of some older bugs. I didn't dig deep into them, but I do believe some were indeed due to the string classes and CoW.

When this project rips out all of the fundamental graphics, replacing it entirely with GFLW it will get rid of a bunch more. Early on everyone had to roll their own graphics. Not the case anymore. We can future-proof this library by standing on top of GFLW rather than having a Wayland plug-in, a Vulkan plug-in, an XCB plug-in, etc. That's a maintenance nightmare and it will always be too far from the source. The team creating GFLW are deliberately creating a single layer API and I believe some of them are even directly involved in the OpenGL, Wayland, Vulkan development themselves.

That one act, and it won't be a simple one, removes thousands of lines of potential bugs from the project.

I need to support desktops only because we medical device developers prototype our code on the desktop prior to cross compiling for the target.

If you know someone who is good with GLFW and wants to take that part of the project on, please let them know about this project.

[ghost]

LeanQt is based on Qt5 and it doesn't have QML. This means you can still rip QML from Qt5. Forking Qt5 and you still have a more modern and advanced codebase than CopperSpice. Qt5 is still being supported. You can clone the latest code from KDE:

https://community.kde.org/Qt5PatchCollection

MSYS2 project also builds their Qt5 using this KDE's fork:

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-qt5-base/PKGBUILD

[RolandHughes]

Start your own project and do that then.