[_rousbound]

I wonder the same thing, but with an emphasis on app mobile development.

Godot from project setup to running on my Android is way more effortless/lightweight experience than doing the way of AndroidStudio and/or Flutter stuff.

What I dream of is making a Lua binding for essential godot GUI control nodes using GDExtension and using this LibGodot to own the engine loop, so I can do all the app code in Lua.

So, I may have drifted away from your question, but the point is that I love Godot for gaming, and I can handle GDScript plus the engine editor, but for writing a complete application I would want to develop in my language/editor/ecosystem of choice.

In that sense, LibGodot(plus GDExtension) may help indirectly developing GUI applications by letting people own Godot in their ecossystem of choice.

[dualogy]

> but for writing a complete application I would want to develop in my language/editor/ecosystem of choice

For well over a year now, you can use an external editor (VSCodium or whatever) and set it in Godot settings (so that clicking a script icon in the scene tree opens that file, and clicking a signal handler in the properties pane jumps to that line), and the LSP for GDScript (which is hosted by your running Godot instance, and which your editor's LSP client connects to) has been excellent back when I last dabbled in it.

[_rousbound]

Yes! I am aware of that functionality, and I've tried it, but this just substitutes the Godot code editor with an external one while keeping the rest of the Godot editor.

In short terms, Godot development workflow has three pieces at least: editor interface(nodes, viewport, etc) + code editor(can be external through LSP) + game/app running.

What I'm trying to say is that app development doesn't strictly need the editor interface at all. For instance, when I'm developing an app with web technology I usually just have a text editor on the left, with my language of choice server side rendering html, and the browser on the right with the "app running".

It would be lovely to spawn the Godot editor and drag around interface components experimenting with them(like the inspector tool on browsers), but usually I just want the peace of mind of having the code and the app running.

So what I'm envisioning is that it would be possible to call Godot in my language of choice just like I would call a normal framework(PyGame in python, Love2D in Lua). With the difference of the powerhouse of functionalities that Godot carries, and the possibility of launching the full editor if desired.

[pwdisswordfishs]

The future of cross-platform toolkits for graphical apps is Godot ("GDTK"?), instead of Electron?

[krapp]

A fork of Godot optimized for native apps would be a good idea. Especially if it learned the lessons of the web stack and used basic text-based formats for describing layout and theming (like HTML and CSS). Maybe something like QT. Something simple, flexible and portable that's as easy to use as Electron but doesn't require lugging around a 60mb Chromium instance for every application.

Some work would need to be done improving text rendering, layout and to add more GUI elements. Probably a lot of stuff removed from the backend that isn't necessary (apps won't need physics or lighting, probably.)

I made a basic theme loader for a project ages ago based on the config file format because dealing with theming and fonts was a pain at the time. Nothing novel, it was just a dictionary that had node paths as keys and set values. It is possible, I don't know why Godot makes some things more complicated than they need to be.

[pwdisswordfishs]

This is how GTK came about. Literally "GIMP Toolkit". They took the widgets that the GIMP creators had created, and turned it into a general-purpose toolkit for other apps to use, due to issues with Qt.

The comments about web stack stuff is probably off. Godot is already a pretty featureful UI framework + form designer that makes anything the "frontend" world has ever produced seem like they only had a fraction (1-to-10%) as much time and resources to build, compared to what Godot was already shipping in 1.0, (even though the reverse is true).