Proposed "LibGodot" Lets You Embed Godot Game Engine Into Other Apps

[ssokolow]

Some how we have to get people to stop repeating this licensing mistake of altering license and not naming it so the mess stops getting bigger.

Maybe create a "license text license" that adapts the "changed versions must have a new name" clause from the SIL Open Font License for licenses that don't just go the "License text is under a 'no derivatives' license so you can't remove the 'no additional restrictions' clause" route that GPL-family licenses do.

[oiaohm]

Maybe create a "license text license" that adapts the "changed versions must have a new name" clause from the SIL Open Font License for licenses that don't just go the "License text is under a 'no derivatives' license so you can't remove the 'no additional restrictions' clause" route that GPL-family licenses do.

Remember parties choose MIT and BSD because they can change the license.

Without need to do nightmare re-licensing places like github and gitlab could mandate all licenses in use must have a header/title and that this header and title in fact be correct. Most people using github/gitlab don't see the remaining problem because most parties just use the MIT/BSD SPDX provided templates. There are cases where the license file has been altered and a diff applied change it that yes these unintended edits down the track can cause major legal trouble. There are also cases of people not understand that MIT/BSD variants exist and that are setting the wrong SPDX. Yes SPDX value has a exact template your license should match.

"The MIT License" as a title is no good because there are too many different licenses that have this as a title.

I see the remaining problems as mostly tooling and regulation of the process as in the software license equal to a spell checker basically is required and enforced by hosting. Without this automated check we know developers are going to mess it up because they have history of doing this. Yes it a valid legal argument having a github project tagged SPDX MIT but it license text is modified is the crime of false product advertisement/fraudulent product advertisement.. At some point someone big is going to get caught by one of the messed up licenses and they will sue a partly like github to cover their damages from the altered license then after that the tooling will be mandatory. Remember messed up license can cause a full product recall so the money being asked for will be ouch.

ssokolow I see this problem resolve itself in time. Smart route would be parties like github and gitlab to get on the front foot and make licenses be label right and enforce this with tooling so developers will not be allowed to get this wrong. The not smart route parties like github and gitlab get sued into doing smart route but the end result will end up the same. I am not sure if this will be year of many decades.

[anda_skoa]

That's sort of like saying "Using Assembly Language to get compactness doesn't necessarily imply writing DOS applications."

Exactly.
Using a versatile language or environment does not imply any specific use case.

One of my biggest reasons for preferring PyQt or PySide over QML is that MyPy's strict mode gives must stronger compile-time checks than QML, even if it's still nothing compared to Rust.

Sure, nothing wrong with that.

QtQuick.Controls 1 is the one that is a wxWidgets-esque wrapper around native controls.

Not really. They weren't even wrappers around QtWidgets, let alone native controls.
They were still mostly drawn by delegating to standard QtQuick elements.

QtQuick.Controls 2 is more un-native to QWidget than QWidget ever was to Mac OS X.

Really depends on the loaded style.

There are styles that do not have a QStyle equivalent, mostly for mobile UI rules like Android's Material concepts.

Desktop styles such as those for Windows, macOS or KDE's Desktop Style either delegate to the respective QStyle or use the same underlying system APIs.

Even if that repo weren't archived with a big "NOTE: This Project is no longer supported or maintained by KDAB." warning in the README, I don't want to add that complexity to my build dependencies.

It builds just as a QML extension plugin, essentially like QtQuick or any other module shipped by Qt.

The point is that it is not difficult to register QWidget classes with the QML type system since the main requirement "derived from QObject" is true for all of them.

So if usage of QML makes it easier for new contributors to engage with a project this would not be confined to those using QtQuick as their UI technology choice.

...and I suspect I'd run up against rough edges. (One of my big reasons for never using QtQuick.Controls is that I always run up against the same problem that originally drove me off GTK+ 2.x, but worse... things that Just Work™ with QWidgets but must be reinvented in other APIs. Last I checked, it doesn't even have a tree view widget.)

I can totally related and I understand that people normally do not quite graps the distinction between QML as the language & framework and QtQuick as one of the modules one can use with it.

My breakthrough was working with QML on the BlackBerry 10 platform which had a very different set of modules for UI and, for that time, more standard controls then QtQuick.

This became even more obvious when I discovered DeclarativeWidgets as it combines the strengths of QWidgets as mature UI component set and of QML as an easy way to create object trees and tie values together.

It's possible I misinterpreted how the API was intended to be used. All I know is that QWidget Just Worked™ and it called the relevant functionality "highlight" while, with with QtQuick.Controls 2.12, I had to override the default behaviour and reinvent selection highlighting to make it feel less "bad Android port".

Yes, probably a misunderstanding.
QtQuick ListView has not provide any highlighting by default since I encountered it first over a decade ago.
To my knowledge that has no changed recently either. I last worked with Qt 6.5's version but I doubt such a behavioral change would have been made since then.

[ssokolow]

Not really. They weren't even wrappers around QtWidgets, let alone native controls.
They were still mostly drawn by delegating to standard QtQuick elements.

I'll take your word for it. I never looked that deeply into them because I was (and still am) waiting for Qt Quick to at least catch up to what I got tired of in PyGTK when I switched to PyQt.

Really depends on the loaded style.

There are styles that do not have a QStyle equivalent, mostly for mobile UI rules like Android's Material concepts.

Desktop styles such as those for Windows, macOS or KDE's Desktop Style either delegate to the respective QStyle or use the same underlying system APIs.

Not really. The Breeze theme for Qt Quick is no more effective at feeling native than the various uncanny-valley Platinum (Mac OS 8/9) themes for Qt and GTK and so on are effective at feeling like Mac OS.

It's not how the pieces look, but how thet fit together and behave... and both Qt Quick and Kirigami are very distinctively not native unless you spend far too much time reinventing nativeness when you could just be using QtWidgets.

It builds just as a QML extension plugin, essentially like QtQuick or any other module shipped by Qt.

And I wish KDE devs would use it, since they're the ones willing to deal with the C++ side of things in their build processes and they're the ones jettisoning Qt Widgets to my growing dismay.

I have high standards for "lay people can feel confident in their ability to run the git version if they want to", which means cargo build or poetry install and, as someone who doesn't have any Windows or Macintosh machines outside his retro-hobby corner, I don't want to be responsible for maintaining wrappers for CMake or what have you to integrate it into that build process.

Yes, probably a misunderstanding.
QtQuick ListView has not provide any highlighting by default since I encountered it first over a decade ago.
To my knowledge that has no changed recently either. I last worked with Qt 6.5's version but I doubt such a behavioral change would have been made since then.

From my perspective, that comes across as "QtQuick.Controls 2 is broken in way X, rather than the way Y that you believed". I do like to have correct information, so I do honestly thank you for correcting me, but it doesn't really change my skeptical eyebrow-raise at claims that it's a production-ready technology.

[anda_skoa]

I'll take your word for it. I never looked that deeply into them because I was (and still am) waiting for Qt Quick to at least catch up to what I got tired of in PyGTK when I switched to PyQt.

As I said I can totally relate.

However it is also understandable that the initial focus of QtQuick had been embedded use cases since Qt already had QtWidgets for desktop.
Nowadays the gaps is really small, not sure if I would be missing any control that is present as a widget.

Well, I guess the equivalent to QCalendarWidget is still in a separate "labs" module.

I have high standards for "lay people can feel confident in their ability to run the git version if they want to", which means cargo build or poetry install

That is a good point, this used to be more complicated when dealing with C++.
Luckily most projects have switched to cmake, so even those are down to "cmake --build" or "cmake --install"

[ssokolow]

That is a good point, this used to be more complicated when dealing with C++.
Luckily most projects have switched to cmake, so even those are down to "cmake --build" or "cmake --install"

As far as I'm aware, CMake still doesn't impinge on the territory of dependency managers like Conan or vcpkg... which is especially important when I want to support Windows users without having a modern Windows PC myself.