11 ms·

This is actually a great proof of concept for using Godot as a cross-platform framework for desktop applications. The distribution package is incredibly simple

by Gormo 3y ago

This is actually a great proof of concept for using Godot as a cross-platform framework for desktop applications. The distribution package is incredibly simple -- just a single executable and a data file -- and performance is excellent. This seems much superior to Flatpak and the like as a way to offer fully self-contained distro-agnostic binary packages, and vastly superior to Electron in the performance department. Maybe desktop applications built with game engines are the next big trend.

eru 3y ago
The Firefox people have some nice write-ups about how they want to / wanted to use techniques from games to make Firefox's UI faster.
jadtl 3y ago
I was trying to think of arguments against it, so I thought about the fact immediate mode GUIs might not always be suitable, before I stumbled upon this post: https://stackoverflow.com/questions/47444189/what-are-the-performance-implications-of-using-an-immediate-mode-gui-compared-to https://stackoverflow.com/questions/47444189/what-are-the-pe... The only other downside I can think about is from a design standpoint, the application has to have the same design language across platforms, so it cannot have a native look for each. Any other cons?
- pants2 3y ago
  I would be concerned about power efficiency / battery life considering the type of rendering it's doing. That would be cool to get some info on.
- 654wak654 3y ago
  Some quick googling tells me Godot doesn't have native tray icons/notifications support or access to peripherals like webcams & printers. Buut if you're using Godot over electron/flutter/QT your app is probably focusing on 3D / physics topics. You can implement plugins for those other niche desktop features as you need them.
  - tmpdbejdhejd 3y ago
    There is some ongoing PR, so it might come at some point : https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aopen+webcam https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aop...
- nucleogenesis 3y ago
  I’ve been thinking about this a bit and the main concern I’ve had is around accessibility. The web has had a lot of iteration over time to make it relatively easy to build applications that are well suited for use with screen readers and other assistive technologies. Have you done any testing along those lines with the Godot UI tools?
- Narishma 3y ago
  It requires a GPU.
  - Gormo 3y ago
    I'm not aware of any GUI stack that doesn't require a GPU, nor any desktop hardware released over the past 30 years that didn't have a GPU.
    - Narishma 3y ago
      Qt or Electron don't; they both have software renderers. The latest Godot needs a GLES 3 or Vulkan GPU. The older versions used to only need a GLES 2 GPU.
      - Gormo 3y ago
        Qt and Electron output to the OS-level display APIs, where screen rendering is handled by X11, Wayland, Quartz, WDDM, etc., all of which still rely on GPUs for output. Godot, as a game engine, bypasses the OS and uses lower-level graphics APIs like OpenGL and Vulkan. But you only need these APIs available regardless of what hardware is under them, and you can use software-based rendering with e.g. Mesa, Lavapipe, or other software renderers. With a 2D desktop application, performance should still be fine.
        Narishma 3y ago
        X11, Wayland and WDDM only use the bare minimum functionality from those APIs, so they work just fine on old DX9-level GPUs for example. Godot needs much more recent GPUs.
        Gormo 3y ago
        It's the use case that requires the bare minimum functionality. Godot might require more recent lower-level APIs than the other GUI toolkits, but if the use cases are similar, then it wouldn't require more performance out of them than the other GUI toolkits would. Using software-based implementations of those APIs would more than likely be sufficient, meaning that there's no dependence on any specific class of GPU.
- hazelnutcloud 3y ago
  I feel like the scripting language (GDScript) is pretty bad. There's no real way to handle errors and its type system sucks compared to typescript. Not to mention you lose out on the diverse packages available from npm.
ladberg 3y ago
This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. I also don't think Godot is inherently more performant for any random UI than Electron is. It happens that most Godot apps are performant because they're made by the type of people who want to use videogame engines and thus care about performance. Electron can definitely have great performance when the developers care about performance (VSCode). I say all this as someone who's worked on game engines before.
- lolinder 3y ago
  Exactly. People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens. VSCode works because they chose Electron for the advantages that web tech has when it comes to building a plugin ecosystem. They were then willing to put in the effort to make performance decent.
  - integricho 3y ago
    I think it's very subjective what is considered performant. I for one don't think about VSCode as a performant app, for me it is a resource hog, not at all that responsive app, there's always a slight delay / lag in input reaction, simply not a fast application.
    - lolinder 3y ago
      So that the rest of us can calibrate, what text editors do you use that you consider to be performant?
      - allan_s 3y ago
        Sublime text or neovim for me (even with all debugger, language server, tabnine etc installed so to be also a full 2024 ide )
popcar2 3y ago
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. [0]: https://alfredbaudisch.com/blog/gamedev/godot-engine/standalone-applications-made-with-godot-gui-softwares-tools/ https://alfredbaudisch.com/blog/gamedev/godot-engine/standal... [1]: https://github.com/mbrlabs/Lorien https://github.com/mbrlabs/Lorien
zengid 3y ago
If you're making a certain class of desktop app (CAD, DAWs, Video Editor) this is worth exploring!
LSRegression 3y ago
It's already being used for that! I use a program called Dungeondraft[1] for easily creating maps for TTRPGS and it's built on top of Godot (see the modding API page[2] where they mention Godot). [1]: https://dungeondraft.net/ https://dungeondraft.net/ [2]: https://megasploot.github.io/DungeondraftModdingAPI/ https://megasploot.github.io/DungeondraftModdingAPI/
- FinalDestiny 3y ago
  To add to the list, Pixelorama[1] is a pixel art sprite editor built on Godot. [1]: https://godotengine.org/showcase/pixelorama/ https://godotengine.org/showcase/pixelorama/
paulmd 3y ago
> This seems much superior to Flatpak and the like as a way to offer fully self-contained distro-agnostic binary packages, and vastly superior to Electron in the performance department. The children yearn for Swing Toolkit
- Gormo 3y ago
  Swing had its issues, along with a lot of advantages over modern approaches to UI.
FireInsight 3y ago
I don't get why people in this thread are conflating Flatpak with different ways to do desktop UI. Even if your app is a single self-contained binary, it can benefit from Flatpak. Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike. That has not much to do with what you use to write UI. Flatpak can't be entirely replaced by self-contained binaries.
- Gormo 3y ago
  > I don't get why people in this thread are conflating Flatpak with different ways to do desktop UI. Flatpak is often used as a solution for creating OS-agnostic distribution packages for applications, by bundling dependencies. This is an example of a solution that provides a standalone binary, obviating the need for the extra complexity of Flatpak. > Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike. These all point out the problems with Flatpak. Runtime sandboxing is unrelated to packaging and distribution, and having Flatpak do both of these things amounts to poor separation of concerns: how do I use a Flatpak package when I don't want sandboxing, and how do I sandbox a non-Flatpak app? The combinatorics of the use cases involved require multiple simultaneous solutions to both package management and sandboxing, which undermines Flatpak's aspiration to be a universal solution. The attempt to unify the package format, apart from being a prime example of XKCD 927, also highlights the complexity of package management as a concept. If you're going to bundle dependencies anyway, why bother with building a packaging solution to include dynamically linked libraries? Why not release static builds that minimize the need for packaging in the first place? The idea of Flatpak being easier on developers masks the attempt to shift packaging responsibility to app devs in the first place -- the traditional approach is that developers just work on their app, and the distro maintainers are the ones who package and distribute it. So this approach is actually extra work for devs. > That has not much to do with what you use to write UI. It's less about the UI and more about the self-contained nature of the executables generated by the engine.
themerone 3y ago
Electron apps work with screen readers and os accessibility feature. Unless accessibility becomes a first class concern, game engines are not going to be good choices for desktop applications.
turtlebits 3y ago
Sounds like you're describing Flutter.
zilti 3y ago
Have you heard of AppImage?
- Gormo 3y ago
  And use it regularly. It's a great solution to test applications out before installing them, or run "portable" applications from removable media or a remote server. But as another of those bundled-runtime solutions, like Flatpak, it suffers from the same issues, including high complexity and poor cohesiveness with the rest of the system.
dataangel 3y ago
This doesn't remotely solve the same problem Flatpak does, you are comparing apples and oranges.
janosdebugs 3y ago
I seriously doubt it. Game engines are, first and foremost, designed to provide a 2D or 3D graphics environment and input handling, they don't typically have the richness of UI components that you would expect for building a desktop app. Godot is no exception here, its UI components are very dated and limited in comparison what modern web-based applications can do. Furthermore, Godot specifically is limited to a single window (apart from popups) last I checked. The other problem with Godot specifically is that every thing is tied to GDScript/the Godot typing system (yes, even the C# and gdextension APIs) and you need to deal with its inconsistencies. I'm currently implementing something as simple as a schema validator (think JSON schema) and it's nightmareishly tough in comparison to any other language I have implemented this in. And then we are not even talking about the almost universal lack of error handling in a large portion of the built-in functions, or really silly things like that opening a TCP connection apparently requiring active polling. I could go on. I love Godot, it's super simple to build game-related things with, but holy macaroni do I wish they had thought things through just a little more when they implemented them. I would never want to build a data-heavy desktop app in Godot.
- TillE 3y ago
  Godot 4 has proper multi-window support. > schema validator > opening a TCP connection You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8. But I agree that any game engine is a poor fit for general applications.
  - janosdebugs 3y ago
    > Godot 4 has proper multi-window support. Could you give me a link please? The Godot editor itself can't do multi-window and I haven't found a clear explanation on how to do that in the games either. > You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8. I use the non-dotnet version of Godot, I'm not happy with the confusing licensing Microsoft has put around .NET [1]. If anything, I'll go the gdextension route, but it hasn't been painful enough yet to do that. For a UI you couldn't ignore the typing system since you'd need to feed the data into it and read from it a lot. [1] https://news.ycombinator.com/item?id=35985832 https://news.ycombinator.com/item?id=35985832
MrYellowP 3y ago
Did you actually do any benchmarks actually measuring CPU performance? Last time I did that was two years (I think) ago and "excellent", even with Godot 4 beta, wasn't what I called it.
simooooo 3y ago
The Godot editor is a good example of a cross platform framework for desktop applications

by Gormo 3y ago

eru 3y ago

The Firefox people have some nice write-ups about how they want to / wanted to use techniques from games to make Firefox's UI faster.

jadtl 3y ago

I was trying to think of arguments against it, so I thought about the fact immediate mode GUIs might not always be suitable, before I stumbled upon this post: https://stackoverflow.com/questions/47444189/what-are-the-performance-implications-of-using-an-immediate-mode-gui-compared-to https://stackoverflow.com/questions/47444189/what-are-the-pe... The only other downside I can think about is from a design standpoint, the application has to have the same design language across platforms, so it cannot have a native look for each. Any other cons?

pants2 3y ago
I would be concerned about power efficiency / battery life considering the type of rendering it's doing. That would be cool to get some info on.
654wak654 3y ago
Some quick googling tells me Godot doesn't have native tray icons/notifications support or access to peripherals like webcams & printers. Buut if you're using Godot over electron/flutter/QT your app is probably focusing on 3D / physics topics. You can implement plugins for those other niche desktop features as you need them.
- tmpdbejdhejd 3y ago
  There is some ongoing PR, so it might come at some point : https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aopen+webcam https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aop...
nucleogenesis 3y ago
I’ve been thinking about this a bit and the main concern I’ve had is around accessibility. The web has had a lot of iteration over time to make it relatively easy to build applications that are well suited for use with screen readers and other assistive technologies. Have you done any testing along those lines with the Godot UI tools?
Narishma 3y ago
It requires a GPU.
- Gormo 3y ago
  I'm not aware of any GUI stack that doesn't require a GPU, nor any desktop hardware released over the past 30 years that didn't have a GPU.
  - Narishma 3y ago
    Qt or Electron don't; they both have software renderers. The latest Godot needs a GLES 3 or Vulkan GPU. The older versions used to only need a GLES 2 GPU.
    - Gormo 3y ago
      Qt and Electron output to the OS-level display APIs, where screen rendering is handled by X11, Wayland, Quartz, WDDM, etc., all of which still rely on GPUs for output. Godot, as a game engine, bypasses the OS and uses lower-level graphics APIs like OpenGL and Vulkan. But you only need these APIs available regardless of what hardware is under them, and you can use software-based rendering with e.g. Mesa, Lavapipe, or other software renderers. With a 2D desktop application, performance should still be fine.
      - Narishma 3y ago
        X11, Wayland and WDDM only use the bare minimum functionality from those APIs, so they work just fine on old DX9-level GPUs for example. Godot needs much more recent GPUs.
        Gormo 3y ago
        It's the use case that requires the bare minimum functionality. Godot might require more recent lower-level APIs than the other GUI toolkits, but if the use cases are similar, then it wouldn't require more performance out of them than the other GUI toolkits would. Using software-based implementations of those APIs would more than likely be sufficient, meaning that there's no dependence on any specific class of GPU.
hazelnutcloud 3y ago
I feel like the scripting language (GDScript) is pretty bad. There's no real way to handle errors and its type system sucks compared to typescript. Not to mention you lose out on the diverse packages available from npm.

ladberg 3y ago

This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. I also don't think Godot is inherently more performant for any random UI than Electron is. It happens that most Godot apps are performant because they're made by the type of people who want to use videogame engines and thus care about performance. Electron can definitely have great performance when the developers care about performance (VSCode). I say all this as someone who's worked on game engines before.

lolinder 3y ago
Exactly. People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens. VSCode works because they chose Electron for the advantages that web tech has when it comes to building a plugin ecosystem. They were then willing to put in the effort to make performance decent.
- integricho 3y ago
  I think it's very subjective what is considered performant. I for one don't think about VSCode as a performant app, for me it is a resource hog, not at all that responsive app, there's always a slight delay / lag in input reaction, simply not a fast application.
  - lolinder 3y ago
    So that the rest of us can calibrate, what text editors do you use that you consider to be performant?
    - allan_s 3y ago
      Sublime text or neovim for me (even with all debugger, language server, tabnine etc installed so to be also a full 2024 ide )

popcar2 3y ago

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. [0]: https://alfredbaudisch.com/blog/gamedev/godot-engine/standalone-applications-made-with-godot-gui-softwares-tools/ https://alfredbaudisch.com/blog/gamedev/godot-engine/standal... [1]: https://github.com/mbrlabs/Lorien https://github.com/mbrlabs/Lorien

zengid 3y ago

If you're making a certain class of desktop app (CAD, DAWs, Video Editor) this is worth exploring!

LSRegression 3y ago

It's already being used for that! I use a program called Dungeondraft[1] for easily creating maps for TTRPGS and it's built on top of Godot (see the modding API page[2] where they mention Godot). [1]: https://dungeondraft.net/ https://dungeondraft.net/ [2]: https://megasploot.github.io/DungeondraftModdingAPI/ https://megasploot.github.io/DungeondraftModdingAPI/

FinalDestiny 3y ago
To add to the list, Pixelorama[1] is a pixel art sprite editor built on Godot. [1]: https://godotengine.org/showcase/pixelorama/ https://godotengine.org/showcase/pixelorama/

paulmd 3y ago

> This seems much superior to Flatpak and the like as a way to offer fully self-contained distro-agnostic binary packages, and vastly superior to Electron in the performance department. The children yearn for Swing Toolkit

Gormo 3y ago
Swing had its issues, along with a lot of advantages over modern approaches to UI.

FireInsight 3y ago

I don't get why people in this thread are conflating Flatpak with different ways to do desktop UI. Even if your app is a single self-contained binary, it can benefit from Flatpak. Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike. That has not much to do with what you use to write UI. Flatpak can't be entirely replaced by self-contained binaries.

Gormo 3y ago
> I don't get why people in this thread are conflating Flatpak with different ways to do desktop UI. Flatpak is often used as a solution for creating OS-agnostic distribution packages for applications, by bundling dependencies. This is an example of a solution that provides a standalone binary, obviating the need for the extra complexity of Flatpak. > Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike. These all point out the problems with Flatpak. Runtime sandboxing is unrelated to packaging and distribution, and having Flatpak do both of these things amounts to poor separation of concerns: how do I use a Flatpak package when I don't want sandboxing, and how do I sandbox a non-Flatpak app? The combinatorics of the use cases involved require multiple simultaneous solutions to both package management and sandboxing, which undermines Flatpak's aspiration to be a universal solution. The attempt to unify the package format, apart from being a prime example of XKCD 927, also highlights the complexity of package management as a concept. If you're going to bundle dependencies anyway, why bother with building a packaging solution to include dynamically linked libraries? Why not release static builds that minimize the need for packaging in the first place? The idea of Flatpak being easier on developers masks the attempt to shift packaging responsibility to app devs in the first place -- the traditional approach is that developers just work on their app, and the distro maintainers are the ones who package and distribute it. So this approach is actually extra work for devs. > That has not much to do with what you use to write UI. It's less about the UI and more about the self-contained nature of the executables generated by the engine.

themerone 3y ago

Electron apps work with screen readers and os accessibility feature. Unless accessibility becomes a first class concern, game engines are not going to be good choices for desktop applications.

turtlebits 3y ago

Sounds like you're describing Flutter.

zilti 3y ago

Have you heard of AppImage?

Gormo 3y ago
And use it regularly. It's a great solution to test applications out before installing them, or run "portable" applications from removable media or a remote server. But as another of those bundled-runtime solutions, like Flatpak, it suffers from the same issues, including high complexity and poor cohesiveness with the rest of the system.

dataangel 3y ago

This doesn't remotely solve the same problem Flatpak does, you are comparing apples and oranges.

janosdebugs 3y ago

I seriously doubt it. Game engines are, first and foremost, designed to provide a 2D or 3D graphics environment and input handling, they don't typically have the richness of UI components that you would expect for building a desktop app. Godot is no exception here, its UI components are very dated and limited in comparison what modern web-based applications can do. Furthermore, Godot specifically is limited to a single window (apart from popups) last I checked. The other problem with Godot specifically is that every thing is tied to GDScript/the Godot typing system (yes, even the C# and gdextension APIs) and you need to deal with its inconsistencies. I'm currently implementing something as simple as a schema validator (think JSON schema) and it's nightmareishly tough in comparison to any other language I have implemented this in. And then we are not even talking about the almost universal lack of error handling in a large portion of the built-in functions, or really silly things like that opening a TCP connection apparently requiring active polling. I could go on. I love Godot, it's super simple to build game-related things with, but holy macaroni do I wish they had thought things through just a little more when they implemented them. I would never want to build a data-heavy desktop app in Godot.

TillE 3y ago
Godot 4 has proper multi-window support. > schema validator > opening a TCP connection You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8. But I agree that any game engine is a poor fit for general applications.
- janosdebugs 3y ago
  > Godot 4 has proper multi-window support. Could you give me a link please? The Godot editor itself can't do multi-window and I haven't found a clear explanation on how to do that in the games either. > You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8. I use the non-dotnet version of Godot, I'm not happy with the confusing licensing Microsoft has put around .NET [1]. If anything, I'll go the gdextension route, but it hasn't been painful enough yet to do that. For a UI you couldn't ignore the typing system since you'd need to feed the data into it and read from it a lot. [1] https://news.ycombinator.com/item?id=35985832 https://news.ycombinator.com/item?id=35985832

MrYellowP 3y ago

Did you actually do any benchmarks actually measuring CPU performance? Last time I did that was two years (I think) ago and "excellent", even with Godot 4 beta, wasn't what I called it.

simooooo 3y ago

The Godot editor is a good example of a cross platform framework for desktop applications