Hacker News Reader

Comment by qw3rty01 | Hacker News Reader

This just reads like a godot advertisement...it only has good things to say about godot and only bad things to say about any other library. It's really hard to take the article seriously with so much blatant bias. It also seems to leave out any technical information that a developer using the engine would want to know, like how well it integrates with existing code, what paradigms it uses compared to other UI engines, or whether it uses lazy rendering or if it constantly runs at 60fps, etc.

View on HN

To be fair the author is writing about his high-level view of the future in the perspective as a big fan of Godot. With that in mind, I think you'll be disappointed by the answers to you questions. On paper, Godot (or any other game engine) obviously makes no sense to most people for these kinds of UI, but having people like the author go against the grain to explore the possibility is great.

It's not a Godot advertisement. The author is just excited about exploring the possibility of using a game engine for UI development. The point of this article isn't supposed to be a full dive into the nuts and bolts of using of Godot for UI development or anything, just a speculative piece about a novel use for this piece of technology. I doubt the author even knows the answers to a lot of the questions posed.

It's just bringing up an option that most developers wouldn't even consider. This article is asking a question, and just focuses on providing enough detail to frame that question.

I don't think the negativity is justified.

The "excited about exploring the possibility of using a game engine for UI development" is fine, the "misrepresenting the alternatives" part, especially while ignoring all downsides of Godot, makes it look dodgy and detracts from the piece.

He’s been very clear about what he does and doesn’t know about the alternatives.

I made this comment when someone was talking about using GLFW and IMGUI to make an application with a openGL window and I think it applies here too, because it is easy to overlook the things that you will eventually need that are not trivial to add once you go down the road of using tools made for only very basic UIs.

"I would bet that the easiest thing would be FLTK. You can use system colors and make an openGL window while having everything else you would expect in a UI library. Executables with no dependencies start at a few hundred KB and it is very fast. There is even a single big pdf for documentation and dozens of examples that show off every widget. FLTK is very underrated these days because no one is out there marketing it.

GLFW and IMGUI are great libraries, but once you start wanting a program with various modal and non-modal windows, menus, widget layout, a native look, file dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables, physical printing, custom widgets, functions to hide OS specific system stuff (like stat, directory listing etc.) you might wish you had started with something made for what you are trying to do. "

Unfortunately, FLTK falls short in at least one important way: it doesn't implement accessibility, e.g. for blind users with screen readers. Godot and immediate-mode GUIs have the same problem.

If I'm not mistaken, the most lightweight cross-platform UI toolkit that draws its own widgets (unlike wx or SWT) and implements accessibility is sciter [1]. It's a good thing the antivirus vendors (who seem to be sciter's biggest customers) want to sell to governments.

[1]: https://sciter.com/

> it doesn't implement accessibility, e.g. for blind users with screen readers. Godot [has] the same problem.

Yeah, this is currently a valid criticism--it's an aspect I'm hoping will see more development attention in the future.

I did recently discover this project which is working on improving the situation: https://github.com/lightsoutgames/godot-accessibility/

That's a closed source for pay gui built on html and css.

It probably would not be too difficult to hook into FLTK's label drawing, but this is a general comment about typical small to medium sized guis, originally as a reply to someone needing an internal tool built around an openGL window. Maybe it would be better to make a top level comment and mention that the game engine isn't accessible to blind users.

IMGUI is still pretty impressive though. You can certainly create modal/non-modal windows, menus, custom widgets, file dialogs, fonts, drag and drop, unicode, tables without any other libraries. It's just that the approach is fundamentally different from what you see in retained-mode GUIs. (And if you need any OS-specific functionality like file dialogs, you can easily use other external libraries)

One of the few weaknesses of IMGUI is theming though. Don't expect to create one of those fancy Material-themed apps with animations, it's primarily intended for creating dry, technical tools of the likes of game engines and modelling/animation tools. It's more in the mindset of creating 'tools' rather than 'apps', and it really depends on your usecase.

IMGUI draws within a window, it does not create new windows. FLTK (like other GUI libraries) automatically uses native file dialogs. Drag and drop means you can drag files into the program, drag strings out of the program, etc. as well as copy and paste in and out of the program. IMGUI is great at what it does, but it does not have native file dialogs or drag and drop. I don't think it interfaces with the OS at all.

> 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)

Godot is also designed to be extensible, so it wouldn't be impossible to just write a plugin (either published or application specific) to integrate whatever app-dev specific features are needed.

It's ok to be excited about stuff and to write about it.

> whether it uses lazy rendering or if it constantly runs at 60fps

This point was mentioned in the article. Seems like you made up your mind without reading too closely.

Reply on news.ycombinator.com