Making Advanced GUI Applications with Godot

https://github.com/julianeisel/bWidgets

While it is possible to hard-code widget positions, with the Container-based layout method the values in that file actually get completely ignored & recalculated on the fly.

The fact that the values end up in the file at all is something I consider a bug/implementation flaw.

In Godot a UI Control has an "anchor" setting for each of left/right/top/down margin which affects where the margin value is measured from in relation to the bounding box. So (hand-waving a bit here), e.g. for, say a margin value of 10px, for the left margin an anchor value of 0 means "inset 10px from the left margin of bounding box" and with anchor value of 0.5 means "move left 10px from center of bounding box" and with anchor value of 1 it calculates relative to the right-most margin. (But for right margin an anchor value of 0 means "calculate relative to right margin of bounding box, and, somewhat confusingly, I think requires the value to be negative to "inset".)

What this means in practice, is that if you use an anchor value of 0 for all margins, even when you resize an element you don't need to adjust any of the margin values.

Unfortunately Godot (and Containers--even though they re-calculate all the margins themselves) default to an anchor value of 0 for left margin and 1 for right margin which means the right margin is a non-zero value & gets re-calculated & updated/save every time you adjust the layout.

In general the layout system works pretty well & is flexible but it does have some slightly confusing aspects (and in the past at least some implementation bugs) and is somewhat difficult to explain in text. :) (And it would definitely benefit from even more detailed documentation--than what it currently has--in terms of the "sizing flags" that determine how multiple Controls occupy/share the space available.)

So, in short: Once set up correctly, Godot UI layouts generally adapt well to different text-widths, font sizes and window dimensions.

It supports this through use of its "Container" UI Controls--which have a bit of a steep learning curve but works pretty well.

> I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics

One aspect of Godot that is a bit different in this regard is that pre-3.0 the focus was very much more on the 2D side of things, so the 2D support isn't just "a flat 2D plane in a 3D world" unlike some other engines.

For context, my interest is in:

* Cross-platform support.

* Ease of distribution.

* Ease of construction.

* Platform stability.

* "Licensing"/business issues.

* Accessibility.

In the past I've used Qt w/ C++, Qt w/ Python, web w/Python backend, Python w/embedded web server and dabbled/looked into things like wx etc. (Oh, and, MS Access with VBA. :D )

# Platform Native UI

If you want/need Platform Native UI, then Godot is not going to work for you, period. But neither are most of the other cross-platform options because if they're only 95% they're not native. My impression is that if you want platform native and cross-platform then per-platform clients w/shared backend implementation is pretty much required.

But I also think that platform native (as much as I might like it) is not necessarily mandatory for successful product, see, e.g. Slack.

I think the key around this is once you've chosen to not be platform native don't pretend to be platform native. Lean into making the UI tailored for your application.

And with a game engine there's a whole lot of space to lean into in this regard--particularly in relation to visualisation.

If you're happy with 95% and don't care about any other aspect then likely Qt will be a contender for you.

# Ease of Distribution

Trying to distribute a Qt + Python app as a single binary (within the last 2 years) was how I ended up ditching Qt & using an embedded web server instead. Despite all the effort & projects trying to make this work, IMO it still doesn't.

With the small initial Godot download and, a (admittedly half gig) "templates" download containing the cross-platform app "shells", it's possible to export to Windows, Mac, Linux, iOS, Android & HTML5. Depending on the platform the output might be a single binary, a disk image, zip file or binary + support files but where required traditional packaging tools can also be used.

This is really powerful for me (as both a developer & user) when the platforms I use (primarily Mac/Linux) are not in the majority & frequently get left out of releases.

# Ease of Construction

In relation to games, the highest praise I have for Godot is:

* Since I downloaded Godot I've actually made and released games.

I've found the integrated nature of the IDE really supports iterative development.

Game-making is often a very collaborative effort and because Godot has been developed (in part) to enable non-developers to not have developers be the bottle-neck it has visual-based tools & a node/component based architecture which also can make it a powerful tool for other technical but "non-developer" people.

# Why not use web technologies?

If your project makes sense as a web site then, make it a web site.

If you want to have a standalone app, you have experience with web technologies and memory/performance aspects aren't an issue, then, sure build it on Electron.

But if you can do those things, you can almost certainly use GDScript and gain the benefit of an integrated IDE and comparatively tiny downloads. (And still export it to HTML5/WebAssembly--admittedly currently probably with a slower initial page load time--but it's still an option.)

Additionally, currently Godot runs on older OS (e.g. even back as far as Mac OS 10.9) than Electron does which keeps getting dragged along to newer versions by Chrome's requirements which seem to place little emphasis on supporting older machines/OS.

# Why not Qt?

Ah, Qt, I really want to like you.

If Qt works for you, then use it.

But my experience with Qt has been one of a business that continually seems to struggle with how to survive; tries to stretch their license compliance in terms of LGPL & contract with KDE to breaking pointing (because, really, they wish they didn't have that constraint at all); and, a continual churn of the underlying technology that results in apps that only support newer & newer OS/Qt versions even if they don't require anything more than, say, Qt 5.2.

If you're a big corporate and/or if a 95% cross-platform solution is enough, then I think there's still situations where Qt probably makes sense but in terms of my niche desktop application development needs it's just too much hassle.

# Is Godot ready for applications now?

Somewhat. Obviously if your application is a game & the required feature set matches Godot's, then yes. :)

Based on my own experience using Godot to develop non-game applications tends to run into some areas of its feature-set which have seen less attention & so have bugs, lack features and/or lack documentation. (e.g. complex Tree controls, more sophisticated font rendering (e.g. kerning), very complex layouts.)

Overall, I think Godot is at a stage where a bunch of people (including OP) have realised it has potential around non-game application development but also has some rough edges in that regard that still needs to be improved.

Given the size & focus of the development team up to this point that's not surprising but I'm excited to see where it may go in future.

# A Note on Accessibility

As mentioned elsewhere in the comments, Godot also unfortunately doesn't currently have a great accessibility story.

There is at least at least one project that I know of that is working on improving that: https://github.com/lightsoutgames/godot-accessibility/

In addition, Godot's node-based UI system in particular I think lends itself to retro-fitting better accessibility support more than a different architecture might.

But if you need your app to be accessible today then Godot probably won't meet your needs.

# Bonus: Are InfoSec tools a potential niche for Godot-based apps?

I think that's a strong...maybe. :)

To explore the potential of Godot for non-game apps I've been working on developing a Godot-based hex viewer/editor with a focus on binary/format reverse-engineering & visualisation motivated in part by a talk where someone complained that hex editors hadn't done much new for years.

Early in development I realised that InfoSec has a combination of aspects that might make it particularly well suited for Godot-based apps:

* Many people who are technically skilled but consider themselves "non-developers".

* Has problems to solve that benefit from new forms of visualisation (often with large amounts of data) not met by standard UI.

* Has an affinity for flashy visuals. :)

* Need tools that don't only run in the cloud.

(In InfoSec and want to make this happen? I'm available for hire. ;) )