To give an example comparing a text field in a native OR webview-based macOS app with a hypothetical Godot-based one, the Godot version would need to reimplement (or likely just omit):
- User's preferred text size and font as selected in System Preferences
- Spellcheck
- Nice features for non-latin text (e.g. built in pinyin keyboard)
- Crisp text rendering
- Dictation support
- Screen reader support
- Autofill
- Automatically updated with OS updates (e.g. HiDPI, all Java UIs had looked almost-native but were now stuck looking pixelated)
- And hundreds more features I'm forgetting...
This is all possible to do in Godot (e.g. the Godot Editor does a lot of these) but with a lot of work required. It's completely built in to any native or web-based text field and doesn't need any additional work.
There's a lot of functionality that a general purpose UI library has that Godot will likely never approach, like support for input methods in text editing.
Productive applications require extremely robust text editing, something that game engines don't spend a lot of time with. Stuff like selection, text input for non-English keyboards, IME popups, that sort of thing. Even RTL text display is usually minimally unsupported.
I also don't know of any game engine that supports multi-window display in any coherent way.
My experience using Godot for 2D games ~1.5 years ago was it was mostly enjoyable but there were annoying little bugs in Mac GUI that didn't give me a lot of confidence. The bad part was when it came to 3rd party library integration for mobile, e.g. for ads, tracking, etc. There's not a lot of support in the ecosystem for those, and writing your own wrappers is a big PITA.
> once you go down the road of using tools made for only very basic UIs.
As noted elsewhere in the thread, the Godot editor (supporting UI, 2D & 3D) itself is built with Godot, so it's definitely not just "very basic" UIs.
FWIW, from your list, Godot doesn't currently support these AFAIK:
* physical printing, spreadsheet tables, a native look
And, does support:
* fonts, drag and drop, copy and paste, custom widgets, widget layout, functions to hide OS specific system stuff [for Windows, Mac, Linux, Android, iOS + others].
And, does support these with some privosos:
* various modal and non-modal windows (v3.2 is all in one window but shows modal/non-modal sub-windows within it, v4.0 in dev supports multiple system windows)
* menus (but not native system menus)
* unicode (Freetype is used for rendering but higher level multi-language support is currently less advanced)
Completely agreed! I've been meaning to write a blog post on using Godot to professionally create cross-platform applications (and probably will soon). The short of it is that Godot is fantastic as a UI builder, and I think a lot of people are slowly realizing it. Many professional applications have been built with Godot[0] , and I also want to give a shoutout to Lorien[1] which is my favorite whiteboard application also made in Godot, and what partially inspired this whole project.
Godot isn't perfect of course, and there are some things that many other UI creating tools do better, but I think there's a lot of untapped potential here.
I recall reading an article here on HN about how that was now a better developer experience for building UIs than writing native apps, with extra bonus that if you want to port, you can.
It builds to cross-platform pretty easily so that is a big bonus. Godot supports C# as well and its own scripting language but not much else. You won't be able to take advantage of native UI elements, but I don't think people care about that as much anymore.
The built-in development environment is mostly non-negotiable (you can supply your own IDE for text editing but thats it) but its well designed and is made to work with its component model. It feels fun to use. The data model also works better with source control than other game engines, but not as well as non-game UI toolkits. If you're a text-environment purist, you might be turned off, but you'd also be turned off by all the big game engines.
I've met developers who use Unity to make mobile apps since the built-in 3D compositing actually makes some applications more performant than the native toolkits. I'd imagine Godot would have similar benefits.
So you think that the Godot IDE which allows code editing will not support robust text editing? I don't know how robust it is currently but there is no reason why it wouldn't possibly support that in the future.
The limitations of Godot's in-engine text editor can be compensated by a more powerful external editor: VScode, emacs, vim, etc.
An example would be the lack of remappable keybindings: this can be overcome by using an external editor.
That said, complete and robust i18n support may take a while, given the small size of the core development team (< 30 regular contributors) and the fact that text display is probably not the highest priority for a game development tool and engine.
- Copy/paste
- Emacs/readline keybindings (Ctrl-A, Ctrl-E, etc.)
- User's preferred text size and font as selected in System Preferences
- Spellcheck
- Nice features for non-latin text (e.g. built in pinyin keyboard)
- Crisp text rendering
- Dictation support
- Screen reader support
- Autofill
- Automatically updated with OS updates (e.g. HiDPI, all Java UIs had looked almost-native but were now stuck looking pixelated)
- And hundreds more features I'm forgetting...
This is all possible to do in Godot (e.g. the Godot Editor does a lot of these) but with a lot of work required. It's completely built in to any native or web-based text field and doesn't need any additional work.
reply