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

[anda_skoa]

You seem to be assuming that I actually like QML, Qt Quick, or Kirigami... I do not.

I did not assume anything regarding your preferences.

Just pointing out that a QQuickWidget can be a nice alternative to QGraphicsView since the original was essentially a direct subclass.

In a lot of cases it is much easier to work with then the QGraphicsView C++ API especially when it comes to constructing elements that are aggregates of other elements.
Not sure what Kirigami would have to do in such a scenario unless you wanted differently styled controls inside our scene, or even controls at all.

[ssokolow]

I did not assume anything regarding your preferences.

Just pointing out that a QQuickWidget can be a nice alternative to QGraphicsView since the original was essentially a direct subclass.

In a lot of cases it is much easier to work with then the QGraphicsView C++ API especially when it comes to constructing elements that are aggregates of other elements.
Not sure what Kirigami would have to do in such a scenario unless you wanted differently styled controls inside our scene, or even controls at all.

That's fair... but I prefer accessing the QGraphicsView C++ API from Python (with MyPy) over using QML and, when I implement compound things in a QGraphicsView, they're generally very simple and/or need to be dynamic and serializable in ways that aren't ideal for QML.

My assumption was that you were looking at it from a "You do fancy, complex scenes in Godot, and QQuickWidget makes complex scenes easier in Qt." direction but my angle is more "Given that it's already been decided that only QWidget is acceptable for native UIs and only Godot is acceptable for fancy, complex scenes, wouldn't it be nice to not have to settle for Godot's non-native widgets when I need a fancy, complex scene?"

Coming from the Qt side, "I don't write fancy, complex scenes". (I generally use QGraphicsView for very simplified Inkscape-esque canvases and, so far, the most I've actually implemented is visualization of persistently visible rubber-band selection on an image containing text to be OCRed)

Coming from the Godot side, "I don't want to reinvent a game engine just to use Qt features".

[sarmad]

This should've been built into Godot from day 1. A game engine should be a library that can be used from anywhere, and the editor should be just an independent tool that helps you build game scenes.

[oiaohm]

A vanity license is a custom license created for a specific software instead of using an established licenses.
Examples of normal licenses are like the GPL, LGPL, MIT, Apache, and the BSD licenses, etc.
Vanity licenses are the Python Software Foundation License, PHP License, Ruby License, and the PostgreSQL License.

It is better if all software uses one of the common and established licenses instead of write their own license. Vanity licenses creates problems such as license proliferation.

its a little more complex than this PostgreSQl gets it license in 1994. In 1994 it was still normal for projects using the MIT license to customize. PostgreSQL license was for the time it was done in 1994 the most common way todo MIT licensing.

https://fedoraproject.org/wiki/Licensing:MIT

Yes this fedora page details the MIT licensing rabbit hole of hell of MIT variant. Like it or not PostgreSQL License is not a vanity license but from a time when MIT license was not a correctly established license resulting in people doing multi ways to attempt to license something MIT making a huge ass mess.

MIT license legal defacto legal disclaimer was only designed to protect MIT and no body else this is also why you still see modern variants of MIT appearing.

uid313 MIT is not a correctly established license and that is why we keep on seeing more and more variants of MIT license. No one is making a MIT license with a correctly design universal protect main project from legal attack so leading to variant after variant with a per project version of this.

I will give you something are vanity license. Postgresql license is just not a vanity license but a side effect of the MIT license collective not having a good universal license for everyone to use. Variant licenses like what we have with MIT is their own unique form of headache independent to vanity licenses. Variant licenses in the MIT case is a sign of big problem with the MIT license eco system itself not each project doing their own version of MIT license doing it out of vanity but instead out of legal need because core MIT license does not cover their asses.

Yes the Redhat employee who got the job at one point to audit the licenses of fedora and rhel was one of the first to document what the problem was with MIT license also documented with a few other licenses that they are Variant nightmares because the core license was not designed as universally used and everyone just fixed the license to deal with their personal problem.

Yes when you see something licensed MIT the question really is what in Variant is this and do remember new Variants of MIT license appear every year quite commonly without a unique branding. At least the MIT variants that put their brand on them like the PostgreSQL one make it clear what MIT variant you are dealing with.

Some areas of licensing are just a complete mess and MIT licensing is one of those areas.
.

[anda_skoa]

when I implement compound things in a QGraphicsView, they're generally very simple and/or need to be dynamic and serializable in ways that aren't ideal for QML.

Right, I see.
So more into custom drawing than into custom object scene.
Makes sense to go with a more explicit API for that

My assumption was that you were looking at it from a "You do fancy, complex scenes in Godot, and QQuickWidget makes complex scenes easier in Qt." direction but my angle is more "Given that it's already been decided that only QWidget is acceptable for native UIs and only Godot is acceptable for fancy, complex scenes, wouldn't it be nice to not have to settle for Godot's non-native widgets when I need a fancy, complex scene?"

Maybe Godot will even get the capability to do native widgets just like QtQuick did.

[ssokolow]

Maybe Godot will even get the capability to do native widgets just like QtQuick did.

Possibly, but it probably won't help much. Getting past the native-ness uncanny valley is HARD and a big part of it has to do with stuff that's not about how the widgets are drawn, but things like how they're laid out.

That's part of why Kirigami fails at that. In the parts of KDE that have been rewritten to use Kirigami, you see things like not-quite-right font sizes, not-quite-right alignments, things intentionally overlaying other things, position: absolute-style, that you'd never see in a proper Win32/Carbon/Cocoa/QWidget/etc. UI, web-style immovable "fake modal popup window" superstitials you can't drag to uncover what you need to double-check, etc.

You'd more or less wind up reinventing "Embed a Godot view inside an otherwise QWidget GUI" but with extra steps and opportunities to get things wrong.

[anda_skoa]

That's part of why Kirigami fails at that.

I might be wrong but isn't Kirigami's goal to have the same L&F across devices, not being native to any as a result?

I was more thinking along lines of going with the platform's style like QWidgets or QtQuick Controls do.

UI, web-style immovable "fake modal popup window" superstitials you can't drag to uncover what you need to double-check, etc.

I've seen those, but I also think this is being worked at on the Qt level.

In the case of a QWidget application embedding a QtQuickWidget that wouldn't likely happen much as the application would create dialogs on the main window side.

You'd more or less wind up reinventing "Embed a Godot view inside an otherwise QWidget GUI" but with extra steps and opportunities to get things wrong.

I don't know.
If the "fancy scene" has need of standard controls it is probably easier to do have them look and feel natively with a library that already supports that.

[ssokolow]

I might be wrong but isn't Kirigami's goal to have the same L&F across devices, not being native to any as a result?

I wouldn't mind that, except that KDE is slowly getting rewritten in it, making my desktop feel more and more like a collection of ported Android apps with a Breeze skin.

I long for the early 2000s, when people lamented that wxWindows (remember how wxWidgets used to be called that?) and Qt weren't native enough on Mac OS. Our standards have fallen so far.

I was more thinking along lines of going with the platform's style like QWidgets or QtQuick Controls do.

Kirigami already includes a port of Breeze and I there's also a "Breeze inspired Qt Quick Controls 2 style". I tried developing against it for something where it'd have been nice to use Rust and the qmetaobject binding instead of having to incorporate Python. It took far too much work just to get the degree of "doesn't feel like a bad Android port" that I got before I lost interest.

(Seriously. That animated list widget highlight in Qt Quick Controls 2 is embarrassingly amateur. I had to basically kill it off and reinvent selection highlight from scratch to ensure there would be no intervals with white text on a white background because it was just a blue box sliding back and forth in a white widget, with the text always being one color or the other, rather than the kind of "always high-contrast" effect they'd have used XOR-drawing for in the early days.)

I've seen those, but I also think this is being worked at on the Qt level.

In the case of a QWidget application embedding a QtQuickWidget that wouldn't likely happen much as the application would create dialogs on the main window side.

"Much" is carrying a lot of weight there. The Window Rules dialog for KWin on whatever revision is included in Kubuntu 22.04 LTS is a perfect example of just about everything I listed, short of the HTML-esque overlay widgets, which are instead irritatingly present in Discover whenever I go to apply pending updates.

I don't know.
If the "fancy scene" has need of standard controls it is probably easier to do have them look and feel natively with a library that already supports that.

Lemmings for Windows 3.1 is a perfect demonstration of why it's important for a game's widgetry to be consistent with itself, at the expense of being consistent with the rest of the desktop... and if it's not a game, then you're back to the Kirigami problem.

Compare the DOS version and, screen resolution aside, tell me that doesn't look more polished. There's a very good reason that style of "make it a Windows application" UI design for games died out early in Windows 95's lifecycle.

[anda_skoa]

I wouldn't mind that, except that KDE is slowly getting rewritten in it, making my desktop feel more and more like a collection of ported Android apps with a Breeze skin.

Interesting, haven't seen any difference so far.
None of the KDE applications I am using regularly have even been transitioned to QtQuick, let alone Kirigami.
And probably won't for a long time, if ever.

From a developer point of view I am not sure why I would use Kirigami styling or components unless I were to specifically create a cross-device application.
If I were to use QtQuick instead of QtWidgets or mixed, I would more likely choose to use the native platform styling.

I long for the early 2000s, when people lamented that wxWindows (remember how wxWidgets used to be called that?) and Qt weren't native enough on Mac OS. Our standards have fallen so far.

Aren't the names the other way around?
wxWindows having been renamed to wxWidgets when they became multi-platform?

In any case a strange complaint against wxWidgets since it wraps native controls as far as I remember.
Unlike Qt which just uses native styling API where available or native styling rules/hints/docs where not.

(Seriously. That animated list widget highlight in Qt Quick Controls 2 is embarrassingly amateur.

Is anyone really using that?
As far as I can tell this is a feature originally needed/wanted by the Nokia Phone UI.

I don't think I have come across any project on either desktop or embedded which used this instead of classic selection highlighting.

"Much" is carrying a lot of weight there.

It does because it is the application developers decision.
Why would I want to create a QtQuick dialog inside a QtWidget application?
Even if I had embedded QtQuick content it would be far more logical to let it bring up the same dialogs that the rest of the application would, no?

Lemmings for Windows 3.1 is a perfect demonstration of why it's important for a game's widgetry to be consistent with itself, at the expense of being consistent with the rest of the desktop... and if it's not a game, then you're back to the Kirigami problem.

Some applications, like games, prefer consistency within themselves or across platforms/devices.
Not sure why you would be "back to the Kirigami problem" is that is not your goal.
Kirigami is especially targeting the former type of software: consistent in itself and/or across platforms/devices.

[ssokolow]

None of the KDE applications I am using regularly have even been transitioned to QtQuick, let alone Kirigami.

The two I'm aware of off the top of my head are System Settings and Discover, because I do interact with them often enough for the design differences to stick in my mind.

From a developer point of view I am not sure why I would use Kirigami styling or components unless I were to specifically create a cross-device application.

If I understood Nate Graham's rationale correctly, it's "If I had to contribute in C++ instead of QML, I probably wouldn't contribute at all".

Aren't the names the other way around?
wxWindows having been renamed to wxWidgets when they became multi-platform?

That's what I said. wxWidgets used to be called wxWindows... but, no. It was multiplatform long before the switch. IIRC, they renamed it when Microsoft noticed and politely asked them to.

In any case a strange complaint against wxWidgets since it wraps native controls as far as I remember.

It does. The complaint is that, even if you weren't going to read the Macintosh HIG either way, a portable API wrapper around the native controls encourages an ignorance of the Macintosh HIG design principles subtly encouraged by the design of the Cocoa and Carbon APIs.

(Seriously, though, even if you're not going to write Macintosh applications, search up a PDF of the 1992 Macintosh Human Interface Guidelines book and give it a read. There's so much in it that's still relevant, but forgotten by modern application developers.)

I don't think I have come across any project on either desktop or embedded which used this instead of classic selection highlighting.

It was the default and the only solution I could find other than disabling it and re-creating it by programmatically changing the foreground and background colors.

Some applications, like games, prefer consistency within themselves or across platforms/devices.
Not sure why you would be "back to the Kirigami problem" is that is not your goal.
Kirigami is especially targeting the former type of software: consistent in itself and/or across platforms/devices.

You're talking to someone who doesn't run a single Electron application, and who avoids in-browser applications whenever a native application is available for exactly that reason.

(EDIT: Actually, that's not quite true. I still need to look up a suitable way to do a sandboxed install of the CLI versions of the A.I. upscalers available through Upscayl so, as a temporary time-saver, I recently installed their webtech frontend via Flatpak and locked it down further with Flatseal. I just use it infrequently enough that I forget I have it installed.)

Games are art pieces. It's OK for them to be unchanging across platforms. Non-games are tools. They're supposed to be so ergonomic that they fade into the background and let the data take all your attention... and part of that is complying with platform conventions as thoroughly as possible.

In other words, they WONTFIX NOTABUG'd "consistent in itself and/or across platforms/devices" and that's the problem.