GodotOS, an operating system interface created entirely in Godot! Browse folders, edit text files, view images, play games, and more in one cohesive polished interface that can even be used on the web.
Note that GodotOS is more of a toy than a serious project. It's meant to push the limits on UI design in Godot while creating a desktop that is minimalist, distraction-free, and aesthetically pleasing. Any feedback is greatly appreciated!
Apologies for posting again, but I forgot to include "Show HN" in the title, and when I did post yesterday Hackernews almost immediately went down for over an hour, which is unfortunate.
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.
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.
I don't believe that either choice is ideal, but if Godot were ubiquitous instead of Electron, applications would probably at least be less laggy and more memory-efficient.
This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms.
I don't think Godot would be a great alternative to developing a conventional desktop app, relying on the OS-provided runtime environment, but if you're already deviating away from that, it might still be much better than Flatpak or Electron.
> Electron can definitely have great performance when the developers care about performance (VSCode).
But most Electron applications do not have great performance because they're not being developed this way. Using Godot would provide an easy-to-learn frontend environment (with a scripting language that might even be simpler than using web-derived JS) while still providing the performance of a game engine under the hood. So non-Microsoft developers who would otherwise use Electron might still stand a chance of releasing decent software.
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.
HTML was never intended for dynamic interfaces. Whenever you diverge beyond what it does best which is hypertext, things become more and more hacky and awkward. If you wanted to design an os UI in electron, you would use a framework called react, and you would use a language called JavaScript that compiles down into typescript and you'd need a whole build ecosystem and connect everything together, then you might find HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg... In both cases you miss the text rendering from HTML. If you stick with HTML then you'd be using css to move shit around and create windows which is also incredibly awkward.
People use electron because it's easy. The reason why it's easy is because of familiarity not because of actual superiority.
Web UI is one of the most hacked together technology stacks ever. Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target. It's not unique in this regard but it doesn't change the reality. Godot has the benefit of a very specific design implementation for a target that is highly dynamic and likely will never change. Plus it's new so you don't have armies of developers trying to "abstract" shit on it over years and years of horizontal progress.
Could you explain this to someone who doesn't program and knows nothing about how os internals?
My naive question is wouldn't the OS/DE/WM still take care of the above for an application?
It probably depends on the app?
Electron will obviously excel at things that resemble an oldschool web page, but one would think Godot would excel at more dynamic OS UIs? If something is already sluggish or GPU heavy in Electron, I would think its right up Godot's alley.
Accessibility of course is a seperate and huge concern.
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/standal...
[1]: https://github.com/mbrlabs/Lorien
[1]: https://dungeondraft.net/
[2]: https://megasploot.github.io/DungeondraftModdingAPI/
[1]: https://godotengine.org/showcase/pixelorama/
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.
Unless accessibility becomes a first class concern, game engines are not going to be good choices for desktop applications.
The children yearn for Swing Toolkit
Last time I did that was two years (I think) ago and "excellent", even with Godot 4 beta, wasn't what I called it.
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.
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.
Games are full desktop applications, ad often have full-featured GUIs overlaid on top of a 3D-rendered playfield.
Certain game genres, especially strategy games and RPGs, regularly implement full UI toolkits, with floating windows, list and table widgets, combo-boxes, toolbars and menu bars, etc. Some games have a superset of standard desktop widgets in order to account for standard UI functionality along with very game-specific needs.
Look at Paradox's grand strategy games for some examples of this. Some people refer to them as "spreadsheet games" because of the complexity of game data and statistics exposed through application-like UI controls.
> 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.
Unfortunately I can no longer find the site, and my Google fu has failed me.
Unlike Hack the Box, no signup was necessary, you could just download the VM and get started.
Does anyone here know of any good alternatives they'd like to recommend?
It would be fun to run in an “anything goes” type setup. Get a cheap raspberry pi and install some really old Linux kernel with plenty of well know holes. I’d worry about delineating between game-machines and real ones. It would have to be totally isolated from the real network I guess.
(Maybe that's actually what Hack the Box is, mentioned in the sibling— I hadn't heard of that and only looked briefly at the homepage for it.)
With film studios increasingly turning to game engines for applications like providing real-time on-set CG as a reference for a shoot, something like this may well be the modern version of that.
[1]: https://docs.godotengine.org/en/stable/contributing/developm...
It was a great way to understand UI and usability paradigms beyond building game mechanics.
This definitely triggered some pleasant nostalgia for me.
I was the creator of Tiagix OS, AFAIK one of the first subOSes that actually had support for creating apps for it.
Learned a lot about GUI toolkits making it, since I had to implement one from scratch for it.
https://forum.gamemaker.io/index.php?threads/gm8-subos-proje...
...actually, is GodotOS any less of an operating system than early versions of Windows?