Live data from Hacker News

Show HN: GodotOS – Fake operating system interface made in the Godot engine

github.com

101–110 of 292 posts

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#101
post #65

Please consider calling it GodOS (pr: gud-os)

Trust me, you aren't the first to recommend the name. I love the idea of saying godos, but then I'd have to constantly explain that it has no relation to God or TempleOS haha

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#102
post #58

Earlier quoted context omitted.

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…

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 fo…

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

Which amounts to a strong argument in favor of using a tech stack that has superior default performance, and therefore requires less dev effort for optimization.

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#103

Very nice! (and AGPLv3 too!!) I have been working on a similar project for actual filesystem/OS interaction (heavily abusing OS.execute ( https://docs.godotengine.org/en/stable/classes/class_os.html )) which is actually a sub-project of a much bigger project (only working part-time now so I can spend half my day on it as I near alpha). My favorite part so far has been in my attempts at using Godot to recreate fsv/fsn…

> Is there any reason you haven't tried to turn it into a real desktop environment given that Godot provides the mechanisms to do so?

It's just too complicated to embed third party applications into a Godot game. I suppose it is technically possible to do so since you can use GDExtension to glue C++ code, but I can't even begin to imagine how that can work. Thanks for the feedback anyways :)

As a side note, Godot can't be GPL because it would imply that you can't make closed source games in it (they'd all have to be GPL as well).

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#104
post #51

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.…

> 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

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#106
post #57

Earlier quoted context omitted.

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-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 con…

It requires a GPU.

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.

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#107
post #102

Earlier quoted context omitted.

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 fo…

> 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. Which amounts to a strong argument in favor of usi…

The problem is that Electron is superior to something like a Godot UI in absolutely everything else.

Sure Godot can be ok for trivial apps, but extracting performance out of Electron is also not that difficult for trivial apps in the first place.

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#108

Earlier quoted context omitted.

Not that much actually if you don't mean as a full WM/DE replacement and instead as an on top layer; Godot 4.2 window management on linux is working quite smoothly for me, including multi-window support. From there what you do within the windows is where the magic happens. (see my other post)

What I mean is a full WM/DE replacement. I mean godot already handles graphics quite nicely. Imagine a desktop that you can control with shaders and runs on Vulkan. That'd be pretty neat.

I've thought about it but it seems daunting so I punted this idea for myself, but it depends on if you mean as an xorg/wayland replacement or if you mean to build on one of those, and even between those two they have a vastly different approach, but there are some minimal foundations that could be built on...

For example, wlroots: "Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway." So it would also depend on if you mean raw WM or if you want compositing also etc.

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#109

Just the other day I was wondering - what would it take to develop a Linux WM in Godot?

> Just the other day I was wondering - what would it take to develop a Linux WM in Godot?

It bas been done :

https://github.com/SimulaVR/gdwlroots

But it is not up to date with Godot 4. You can have your Firefox or Blender window be a regular texture inside a full Godot game, pretty crazy...

Re: Show HN: GodotOS – Fake operating system interface made in the Godot engine

#110
post #58
post #51

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.…

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…

VSCode is super laggy even on a $4000 MBP. Compared to something like IntelliJ sure, but that's a super low bar on responsiveness.
Post reply on HN