I built a couple of desktop utilities with Godot, and they work fine on both Mac and Windows (I didn’t need to use them in Linux since they are mostly file grouping/management things). Pretty solid.
The one thing I don’t like about it is that you can’t really get the apps to look “native” in any shape or form, and that you have to roll your own widgets for a few things (which is why I went back to some of the wxWidgets stuff I have listed in https://taoofmac.com/space/dev/native)
I'm happy to see that this usage of Godot has continued. I've been interested in using Godot for application development since I saw their official "Apps & Tools - 2022 Showreel"[1] video. The only concern I see commonly mentioned is in terms of accessibility (lack of screen reader support, etc.) - which could be a major drawback for certain types of software.
I love Godot for games but it's clearly not designed for utilities. The editor constantly uses a percentage of my CPU doing absolutely nothing. I don't think Godot executables can stop redrawing the window, only lower the FPS. I don't want my applications to be like that.
You can enable low-processor mode to reduce CPU & GPU usage. See related FAQ https://docs.godotengine.org/en/stable/about/faq.html#is-it-...
This is with low processor mode enabled. Hell, it's still true when I multiply Low Processor Mode Sleep by 100. This is a blank default project that has a single empty node--and the window is minimized.
Yeah, even disabling a bunch of things and pausing the scene tree, Godot still uses 5% of my CPU (i3-6100T):
func _ready() -> void:
set_physics_process(false)
PhysicsServer2D.set_active(false)
PhysicsServer3D.set_active(false)
Engine.max_fps = 1
RenderingServer.render_loop_enabled = false
get_tree().paused = true
Some post on HN discovered that app rendering would be more efficient if we did that (somebody made that the research of their life). Unfortunately i can't find the link anymore
You don't need to keep redrawing the window. If the content isn't changing, Process will be called but you don't need to queue a redraw.
What is the deal with accessibility & godot?
That's largely my concern with Dear ImGui et al. It's okay to have it as a debug environment in a game, it's not okay to have it as an application. The lead developer agrees: "I do know that Dear ImGui unfortunately does not align with requirements of accessible software. It was designed as a technical/debug tooling software to be used as an overlay over 3d/graphics applications which themselves tends to have little to no accessibility features. It's not really my fault that people have started using it for desktop-ey applications." (GH issue 7892)
Unfortunately I don't think this is great out of the box. Godot renders using very low level graphics API, which I believe would bypass any OS-level accessibility features. However there is work being done in this area, specifically for blind users: https://github.com/lightsoutgames/godot-accessibility
I've written an article about why I think Godot is a good tool for general app development, not just for building games. The article talks about my experience working with Godot for a mobile app for musicians, as well as some insight from a WIP game project. At the end there is a list of other tools and applications that are built on top of Godot.
I hope you find it useful!
Well written!
Hey, it's also a good idea to post a link to your article on https://www.reddit.com/r/godot/
Already done so, but thanks!
I agree but I just wish, I wish it had three things: - customizable native menu bar - native file dialogs - drag & drop support from the outside world
that would make it would be an excellent option for desktop app development.
Lucky you, godot does have those features, although a bit limited to an extent.
For native file dialogs, see the methods file_dialog* in https://docs.godotengine.org/en/stable/classes/class_display...
Not quite sure what you meant by drag & drop, but godot has API for getting the files dropped onto the window: https://docs.godotengine.org/en/stable/classes/class_window....
Finally, you can create (or customize?) native menus: https://docs.godotengine.org/en/stable/classes/class_nativem...
Also, slightly unrelated, I have WIP useless desktop widget created with godot https://github.com/nvlled/fps-desktop that shoots a gun on mouseclick. Tested only on linux.
I wasn't aware of the dropped API - good to know. The gun thing is excellent, thanks for sharing!
Native file dialogs would be nice, agreed. Same for drag and drop support. The great thing about Godot is that it is, after all, "just" an open source application written in C++, and if someone wants to add support for this badly enough it is definitely doable, especially if you limit yourself to just one or two platforms.
As for menu bar, why do you think a native one in particular is better? Godot has great support for menu bars already, and I'm just not sure what the native one would add to the table.
Things might have changed since 2013, but the user is this post had their SFML game rejected by the mac store because of the menu bar not meeting spec. https://en.sfml-dev.org/forums/index.php?PHPSESSID=ce5jim0on...
I just don't want to put all the effort into a cross platform app for it to be rejected for the same reason.
Usually using game engines for app development isn't a great idea given the things they were never designed for in first place.
Unlike most other game engines, Godot has been designed from the very start to build a very specific application... The Godot Editor! Features for building the Editor have been added to the engine since the beginning of development.
So I assume it does input validation of form fields, with assistance for introducing values for people with disabilities?
It also supports a collection of component libraries for most use cases of LOB application?
Integration of desktop and mobile OS APIs for OS and interapp communication and extension workflows, e.g. tray actions, file management context menus.
The article doesn't recommend it for LOB applications at all.
Your questions would be perfectly cogent and understandably pointed in response to such a claim, but the author clearly isn't proposing that.
Silly me, I thought the point was about app development suitability, or lack thereof, without any "yes, but".
That's not at all how I took the article myself.
(and I noticed the comment you were replying to was from the author thereof so under the circumstances it seemed reasonable to use what he'd written about it long form as context)
Too bad the rest of it hasn't been dogfooded nearly that much! The user experience on stuff like setting up animated sprites, tilemaps, etc. is still pretty uncomfortable. And all the UI stuff is very clearly designed for building desktop applications instead of, you know, games.
This is a really strange set of complaints. Could you clarify what you mean?
Very interesting- coincidentally I’ve been evaluating Godot for my own needs. Many apps have a “gamification” element that in my experience can feel clunky to implement on some frameworks- it then clicked for me that a game engine might be a better tool for the job
Great article. Another example I'm aware of is Blockhead, which is an experimental DAW that focuses on sampling and audio clip manipulation. The creator (@ColugoMusic on Twitter) regularly posts clips and progress, which I find fun to follow.
Yes! I was vaguely aware of a DAW project in Godot, just couldn't remember the specifics. A DAW seems like a fantastic application because Godot has great support for playing sounds thanks to being a game engine.