Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: GodotOS – Fake operating system interface made in the Godot engine (github.com/popcar2)
534 points by popcar2 7 months ago | hide | past | favorite | 280 comments
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 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.


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.


I have never encountered an Electron app that can even display the results of keystrokes in a timely manner, and that includes vscode. All Electron apps waste system resources to an obscene degree. Also, Electron apps have already thrown away OS conventions to the point that user interface consistency has become a thing of the past.

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.


Something is very wrong with your system configuration if VS Code has issues showing keystrokes in realtime. It's not a VS Code or electron problem.


I've had this happen with VS code. When your system is under load, VS Code not only gets keystrokes in a laggy way, the characters arrive in the wrong order.

Haven't had this problem with other text editors.


Yes same experience here, it'll perform well for the first 3 keystrokes after a rest, then start lagging, compounding lag to the point where the screen is 5 characters behind of what I am typing, then I have to wait 10-15 seconds for it to rest and report all the errors. It's terrible but there's no alternative for the features.


That's entirely different than having "never" seen it handle keystrokes in a timely manner.


I've seen this too. With recent versions nonetheless.


VS code has had 1 or more frames of keystroke latency on every system I've ever used it on (across years of regular use, on multiple devices and OSes).

It's imperceptible to some. Not to me. Drives me up the wall, but the vscode integrations are too good.


People say this but then I look at them typing and I can literally see the lag compared to closer-to-the-metal toolkits.


This happens to me pretty regularly when training ML models or running heavy simulations etc, the system is taxed and electron just gets swamped meanwhile more efficient apps can handle themselves just fine on the side.


Except, maybe, for the fact that they are attempting to run anything Electron at all on their device, it is not a configuration problem to use a machine that was manufactured a couple years ago and was most likely not top-of-the-line hardware even back then.

(In my particular case I've a passively cooled laptop from like 2021; The limited compute resource available to applications in that device really made me appreciate the well built applications)


I currently use an old macbook from 2014. Everything is slow and I can't have too many applications open at once. But vscode is still one of the snappier ones and I don't see those keystrokes issues.

Of course you can always go less powerful but at one point you just can't use all more complex editors. It's not an electron issue.


Vscode struggles with intellisense and vm round trips on my older cpu. Feels like a race between displaying the character I just typed and displaying suggestions. Sometimes.


to be fair, it's possible that I also experience this from time to time. Since it's an old laptop, sometimes things are slow and I have to wait a bit for intelligence to initialise and cache results. But generally, especially if I close most other programs, it feels reasonably snappy and I don't have the displaying issue.


As an OSX user I had problems with VS Code only on 2 occasions: 1. Syntax highlighting gives up on larger files. What can be considered "large" depends on your machine of course. In this situation I use Sublime Text. 2. I worked on a web frontend that used React MUI (Material UI). That particular version of MUI & VScode combo didn't work at all. Intellisense would slow the editor down to where it was barely usable. That was a couple of years ago, never seen this issue again.


Try opening a 100 MB file in your text editor and report back.


I have the same not-a-VS-Code-or-electron problem.


Sublime Text and Blender (and I guess the majority of CAD applications) creates their own UI engine. That would be better than the current state of electron apps, but most UI engines I encounter have support for custom elements. The issue is more wanting access to lots of cheap developer resources than branding.


I'm not sure about Sublime Text, but I can't imagine Blender is very accessible. As it's such a visual app that's perhaps not surprising, but this approach wouldn't work for other app styles.


Are you running a 15 year old netbook or something? I've never noticed any input lag in VSCode or Slack (or any other Electron apps I can think of)


I own a 2017 MacBook Air, and I don't see why a block editor like Notion should be so slow on my computer. This is why I'm building my own block editor in Qt C++ and QML[1].

[1] https://www.get-plume.com/


Nice landing page. Tip: make the speed comparison an agonizing animation, like esbuild's:

https://esbuild.github.io/

Edit: Tip 2: the screenplay looks nothing like a screenplay


Haha that's funny. I'll consider that.

> Tip 2: the screenplay looks nothing like a screenplay

Is it because the lack of middle alignment? I was thinking about that. At the end of the day it's all plaintext/markdown underneath, so I need to come up with the right syntax for that.


You can use Fountain

https://fountain.io


Awesome, thanks!


Just wanted to compliment your landing page and the intro gif. Great showcase of the app, if I wasn't hooked on LogSeq I'd give it a try!


Thanks a lot, I'm very happy to hear! Essentially, all notes are just markdown/plaintext, so it should be easy to move your data to/from LogSeq. I'm saying essentially tho cause, although the underlying data is plaintext, they are stored inside a local database rather than an arbitrary folder. But soon I'll change that.


Because Notion is slow period. The web app is insane


Looks good. I joined the waitlist.

How does it compare to Obsidian? I didn't see it in any of the comparison graphs.


Hey there, just saw your comment. Obsidian isn't a block editor (see below what it means in practice) so it's not being compared.

- Obsidian is using the resource-hag framework Electron. So it uses much more resources. Plume is built using Qt C++ and QML, and it's actually faster than comparable native apps.

- Obsidian editor is not a block editor (i.e., like Notion), so you can't put advanced blocks like a Kanban (tasks board) within the same page.

- Since it's not a block editor, you can't drag & drop different components.

Unlike Notion (which is also a web app wrapped with Electron), Plume is:

- Fast (Qt C++ vs Electron)

- Easier to use (opinionated design vs. Notion's complex databases)

- Portable (Underlying data is plaintext* vs. proprietary database)

*Currently all the notes' plaintext is stored in a database, but soon we'll change that to support arbitrary folder.


You're probably used to high latency.


You'd be, if you got into computers only recently. It got this bad.

Only those who have used systems yielding low input latency (e.g. Commodore 64, BeOS or the Amiga) can tell that something is very wrong.


What does low latency have an effect on, productivity?


Sanity.

Whether sanity and productivity are correlated, I won't go into.

When you've experienced low latency, high latency is very noticeable, and drains mental health.


Yes, that's the most probable. I use a M3 Max so nothing is really slow but speed difference between vscode and Sublime is abysmal.


they're a text editor and a chat client, and a 30 year old computer can run vim/emacs and irssi just fine.


brb, just switching my 100k employee company from Teams to IRC, should be quick and easy, everyone is going to love it.


If they are on MacOS they may make you their king. I still have PTSD from the last job that I had to use Teams on a Mac.


Teams is awful on all platforms, I don't ever want to touch it again


They might indeed. There are some very nice native IRC clients for macOS that are fast and good...


Excellent idea! You'll have a mature, open standard protocol under the hood, with no vendor lock-in, excellent extensibility, and great modern frontends like The Lounge (https://thelounge.chat/) or Convos (https://convos.chat/) to choose from (and you can choose).


I would love it. I would also love for it to switch to silence instead.


VS Code ID top laggy for you? Honestly asking because I think it performs adequately when compared to like IntelliJ.


According to one benchmark intelliJ can reach an average latency of 3ms on an i5 3427U from 2012 [0]. In a 2022 Github issue someone profiled VS Code which resulted in 12ms latency on an i7-12700KF released in 2021 [1].

If those results are even remotely representative of real-world scenarios then VS Code can't come close to intelliJ performance.

[0] https://pavelfatin.com/typing-with-pleasure/#windows

[1] https://github.com/microsoft/vscode/issues/161622#issuecomme...


When doing what? Also why did you leave out that in the actual apples to apples comparison (the screenshot in the GitHub issue), IDEA literally is shown to have a worse latency versus vscode. Also, just going by pure graphical latency is... niche to say the least. What matters most is how fluid it is, how quick it actually processes stuff and how well it does all the required background IDE stuff without lagging or loading too slowly. Painting onto the display is just one part of the equation (and one that vscode still seems to beat IDEA on, even in a bug report about latency on... vscode)


If you want to check an application that runs on Electron and is quite speedy, try Obsidian.md. I didn't even know performance like that was possible in an Electron app. Unfortunately this example is the exception instead of the norm.


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

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.


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

Flatpak and Electron don't sabotage any of these things. Flatpak usage is entirely orthogonal, and Electron actually has best-in-class accessibility, i18n, text rendering, keyboard navigation, RTL support, hi-DPI support, etc.; its widgets feel by default as-or-more-native than anything Qt or GTK produce.

Without massive engineering work, handcrafting your GUI in Godot is going to suck for anyone using a screen reader, anyone who reads Arabic, anyone who can't use a mouse, etc.


Trying to come up with a way to open this without "well, actually..."

Godot UI components are keyboard accessible by default and do support Arabic. I haven't tested them with a screen reader so I have no data there.

The Godot editor itself is made in Godot, and it doesn't feel particularly snappy when compared to vscode, so I agree with the general premise that it wouldn't be a huge step forward. That said, it is more accessible out of the box than you might expect.


> Flatpak and Electron don't sabotage any of these things.

Flatpak does, you need to give access to xdg-config/fontconfig to each flatpak or globally for it to respect your fontconfig settings. I've hit this, and it's one of the reasons why I don't use nor want to use flatpak.


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.


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


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.


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

Why? What capabilities does Electron provide that Godot doesn’t and can’t? I’m genuinely asking. I don’t know.


Electron has literally thousands and thousands of very, very complex UI/UX features offered by the OS, plus thousands and thousands of very, very complex UI/UX features offered by a browser engine.

Godot has barely nothing compared to that, as it's not an UI toolkit and never tried to be.

Even basic things like "rendering text correctly in multiple languages, with emojis, while making it selectable with the mouse or with the keyboard" are super hard to get right, but it's a problem already solved by your OS, in a way that is not only better optimized and has less unseen bugs than a hypothetical bespoke implementation: it also looks and feels more familiar. Then there's the whole accessibility part, which has different native APIs depending on the OS.

Some other people have written detailed answers:

https://news.ycombinator.com/item?id=38953558

https://news.ycombinator.com/item?id=38954455

https://news.ycombinator.com/item?id=38954087

EDIT: You asked "doesn't and can't". Here's something: there is no can't if you have a turing complete language. But you need a large team to re-do it from scratch, as you're throwing away 40 years of work.


Video game engines absolutely handle text rendering across a wide range of languages. Not all games involve complex text input, but it’s a sufficiently common need that’d I’d expect a generic engine to support robustly.

Accessibility is often language in game technology. That should be better.

To be honest my first reaction was negative to this idea. But if your comments and links have done anything it’s convince me that maybe this isn’t a bad idea after all!


> Video game engines absolutely handle text rendering across a wide range of languages.

They handle specific subsets of text rendering across a wide range of languages. There's a ton of interactions with the OS-level text interactions that are both difficult to fully enumerate and even more difficult to re-implement non-natively. Font programming can get really, really complex—some of it might be perceived as unnecessary—ligatures, proper kerning, certainly sub pixel rendering, glyph variants, arguably emoji—but others will really suck, like poor interactions with highlighting and cursor movement; replicating native keybindings; replicating differences in how e.g. linux and Macs kill, yank, copy, cut, paste, etc; replicating differences in how "paragraphs" are split into "lines" (logical or visual?) across platforms.... this isn't even touching the complexity of processing input (do you really want to implement wubi chinese? Do you know how to properly handle unicode normalization the same way the local editor does so that typing the same keystrokes causes the same behavior? how about differences between punctuation glyphs between scripts? Are you even handling hyphenation correctly? Does it reflow as expected when the layout constraints change?) and simply processing unicode in a consistent and well-behaved manner.

(and of course this isn't even touching attributed text or rich text editing or combining fonts on a single line....)

> Accessibility is often language in game technology

I'm no expert, but accessibility concerns must be wildly different in a game than in a data-heavy or prose-heavy app. I can't imagine implementing a screen reader without relying heavily on the OS....


> They handle specific subsets of text rendering across a wide range of languages.

People radically overstate how hard this is. Yes there’s a lot of cases. But God bless UTF-8 which provides a very clear path.

There are countless hobby text editors and libraries that handle literally all of this.

> I can't imagine implementing a screen reader without relying heavily on the OS....

Of course. You “just” need to use the documented OS APIs. It’s not trivial. But like it’s not that hard to use the APIs that lots of programs and libraries already use.


> There are countless hobby text editors and libraries that handle literally all of this.

The thing is, there really aren't. Certainly not that I would characterize as a "hobby" text editor.


> But God bless UTF-8 which provides a very clear path.

It's a very clear middle finger for CJK users if text rendering issues were dismissed because "we do UTF-8." Thanks to the Unicode Consortium, letters from CJK languages have shared code points in Unicode. This makes it very easy to have, for example, Chinese style fonts sprinkled over Japanese text. This kind of mixed styles are aesthetically inconsistent, unpleasant, and hard to read.

https://en.wikipedia.org/wiki/Han_unification

i18n is very much not about slapping on UTF-8 support and calling it a day.


> i18n is very much not about slapping on UTF-8 support and calling it a day.

Every major game engine has robust support for internationalization. It’s a strict requirement for professional video games.


I never said it was impossible, I just said that a lot of what's currently possible in game engines is absolutely dogshit compared to even Electron. This is not really an opinion, the features just aren't implemented yet, and UX is not a concern.

And I never said video games can't handle text. I said it currently can't do it at the same level as the OS or browser, with all the features.

Implementing is of course possible. But unlike something like React Native, or Electron, if you want to keep the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. The ceiling here is something like Flutter, which cost Google millions of dollars.

It even remains to be seen if performance will be even comparable to Electron if someone implement all the missing features.

> "Accessibility is often language in game technology. That should be better."

There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.


> And I never said video games can't handle text. I said it can't handle at the same level as the OS or browser.

The actual metric is “can they handle text at a sufficient level”. I’m inclined to say yes.

> Due to the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch.

Oh baby don’t threaten me with a good time.

Web browsers are kinda terrible at UX. Native mobile apps are sooo much better than web.

> There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.

It’s weird that you say “nothing to level of electron and therefore must start from scratch”. As if there aren’t already libraries and utilities to build off of. At the end of the day electron “just” uses the documented Windows API! It’s not a trivial project. But it’s hardly insurmountable.


Hmmm, I don't know what's this about "actual metric". Is it "sufficient" for simple projects? Sure. Is it as good as Electron in terms of UX, and look/feel? No, it's not even close. Because Electron is doing native rendering.

Let me try to explain a different way:

- You are saying that native is better. Sure. UX is better, look and feel is better, rendering, accessibility (in most cases), consistency, configurability.

- Electron leverages native for a lot of functionality, so it is able to provide good quality. With light styling and semantic tags, it will use a lot of native functionality and will look exactly like the OS.

- Game engines can't use native to the extent that Electron does, because the rendering model is fundamentally different (as explained in one of the links), so it must use libraries that don't exactly have the look/feel/quality of native and must simulate it. It doesn't get as far from native than that.

> It’s weird that you say “nothing to level of electron and therefore must start from scratch”.

But this is true. There is currently nothing close to Electron accessibility in the game world. I'm not talking about base-level accessibility. Check the kind of accessibility provided by browser engines and operating systems, and you'll see it is a lot of work already cut out for developers.

Are there libraries? Of course there are, I never disputed that. I actually managed to sneak a few commits and opened a few issues in AccessKit, which is a Rust accessibility library that can be integrated with game engines. But it's still early days compared to what Electron can do.

Browser accessibility is actually really great, and it's virtually automatic for developers. I would say that only Apple has as good/simple accessibility as browsers. Check these posts to see the opinion of a Microsoft alumnus that specializes in accessibility: https://news.ycombinator.com/item?id=27338151 https://news.ycombinator.com/item?id=24188387


I will grant you that Accessibility is not handled well.

But I don’t find any of the other arguments compelling.


Sure. But there's no argument here. Me and others are merely answering your questions. You said above "I'm legitimately asking. I don't know." I'm assuming this was said in good faith.


That’s fair. It was good faith. Thanks for engaging. I’ll leave it at that.


Electron allows you can do webdev stuff, so you don't need custom knowledge of anything special. That's the 'superiority'.

Doing UI in Godot means either their pythonish custom language or C# (and via GDExtension technology, C and C++ ).


I mean, I've never used Godot, but from my usage of Unreal, Unity, and a couple of proprietary engines: while I hate webdev and the way Javascript evolved, every game engine's UI solution has shown me that the US workflow is still way ahead of games'.

Maybe Scaleform or other flash based UI frameworks solved this problem elegantly for games, but it died ahead of my time.


I think that you might find that Electron has perfectly fine default performance! Think about filling out an <input> field in your browser that doesn't have any weird magic on it. It's basically instant right?

The issues come from stuff like autocompletion tricks etc leading to weird lagginess. People get a first version of a thing working, and then it just kind of exists in that state forever.


I think that it instead amounts to a strong argument that many apps simply wouldn't exist if Electron didn't lower the barrier of entry.


VSCode is slow as heck and a needless memory hog. Something like VS6.0 or Code Warrior with crisper fonts would be my first choice on a graphical interface.


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.


So that the rest of us can calibrate, what text editors do you use that you consider to be performant?


Sublime text or neovim for me (even with all debugger, language server, tabnine etc installed so to be also a full 2024 ide )


SublimeText, Notepad++, CudaText and LiteXL have acceptable performance, memory footprint and responsiveness for my taste (but this is certainly not a benchmark, just another subjective viewpoint :) )


Lite XL, although I usually use Emacs


VSCode works, because Microsoft has written a ton of C++, C# and Rust code to make it work in a usable manner.

Exactly what most devs reaching out to Electron don't want to do, only cozy JavaScript.


Except VSCode most certainly does not have great performance. I can open the same set of files in VSCode and Sublime, and Sublime will use a few hundred MB of memory while VSCode uses well over 1 GB. That's not acceptable.


No it's better for an os UI. A web page UI is better with electron where you click on a link an open a page. But floating windows with resizeable and highly dynamic UIs Godot is likely easier, better and much more well suited.

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.


> HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg

HTML is replaceable by WebGL which is replaceable by SVG?

> JavaScript that compiles down into typescript

JS compiles down to TS?

I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL

Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/

Here's one that mocks macOS - https://macos-web.app/


>JS compiles down to TS?

It's called a typo.

>I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL

I think you're smart enough to recognize it's a typo. The primary issue with your comment is hiliteing issues as if it weren't typos but actual lapses in experience. It's like saying someone misspelled a word and claiming they therefore have no experience with the English language. If someone did that, the intent is 100% malice, not a misunderstanding. Don't be malicious. Don't debate and use malice to prove a point. What you should do is Make a point and change your stance based off of evidence.

Also I never said it can't be done. I said it's awkward. It certainly can be done.

WebGL is low level. Same with WebGPU, it means you have to use shaders. Godot has a library for UI. Which makes it less awkward. I'm saying it's JUST as awkward to build these things with webGL then with other web front end technologies.

>Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ >Here's one that mocks macOS - https://macos-web.app/

What do these examples prove? That it can be done? Did I say it can't be done? Again I didn't. It's obvious these examples exist, everyones seen them. Heck you can probably do the whole thing with CSS and no JS. The gist of my comment is that it's awkward to do, not that it can't be done. You can construct a house out of toothpicks and glue. I'm sure it CAN be done. But bricks are the less awkward tool.


I'm another person who read your comment who doesn't like Electron/web dev and, while reading your comment, I thought "does this guy even know what he's talking about?".

So as someone aligned closer to your team (preferring other toolkits to Electron) I don't think the other user who replied to your comment previously was being malicious in interpretation.


So did you think i actually meant that Javascript compiles down into typescript?

I'm sorry but that comment alone makes me think malice. It's too obvious. To each their own.


Yes, I did and I was confused (hence my thought it was someone focusing on things other than web dev that made the comment).

It's not like I'm attributing ill intent now that you've clarified what you meant (I mentioned having the same anti-Electron inclination as you to demonstrate that) but I probably can't change your mind if you think two people's misinterpretation of the same comment came from malice.


Such typos are common and obvious.

It's more likely someone utilizes such errors as ammunition. Such an action is quite common. It's obvious to me that this is the more likely scenario here from the other replyer.

Another common thing is to team up with people who have similar intentions. When such a situation happens they synchronize their biases. Two coworkers with the same intent will synchronize their biases in a meeting in order to push their intent... Happens all the time.

You like the front end, my guess of what's going on with you is a team up of sorts. Malice is too strong of a word for what you're doing. You're doing a team up and you're adjusting some obvious biases to favor your intent and create alignment with your team mate. This is all done subconsciously too. But that's just my guess on what you're doing.

These are all obvious human behaviors that are quite common but people don't think about it until it's explicitly pointed out.

But in the end. Who cares. We both are now clear about what's going on. No point in debating this further.


> Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target

Bullshit. React is almost 11 years old, the only other two really popular competitors are 10 and 13 and use the same paradigm.

Everything else in this area is very experimental and tentative, as it should be, but it is mostly celebrated by people who, surprise, complain that "the web is too complex".

Even "new hotness" like Tailwind is based off quite old Atomic CSS ideas that started in the late 2000s and early 2010s at Yahoo.


>Bullshit. React is almost 11 years old, the only other two really popular competitors are 10 and 13 and use the same paradigm.

React has been changing a lot. And before react it changed even more. There's all kinds of change in the front end world and you know it. Not even close to bullshit.

>Everything else in this area is very experimental and tentative, as it should be, but it is mostly celebrated by people who, surprise, complain that "the web is too complex".

Webgl and svg are experimental? I don't think so. Using CSS + HTML + Javascript to build an Windows like application is more experimental.

>Even "new hotness" like Tailwind is based off quite old Atomic CSS ideas that started in the late 2000s and early 2010s at Yahoo.

I never talked about whether something is based off of old technology. I'm just saying all the state of the art is always changing constantly as people build new things. Whether those new things are recycling old ideas is besides the point. The main problem is that each "new" thing is placed as this big ugly layer above something that was designed to be a high level interface anyways.


React had a single major incremental change in the form of hooks. It was built upon existing established foundation: functional components. And even then, it still didn't break backwards compatibility. That's far from "changing a lot" in 11 years.

And "before react it changed even more" is a terrible argument. We had a handful second-tier frameworks who never gained enough traction compared to React/Vue/Angular even in their first months. None of those temporary frameworks achieved more than a very small fraction of jQuery popularity in their heyday. jQuery was king since almost launch, and was never really threatened, until React came along.

By "in this area" I obviously mean frameworks. And good call: WebGL is gonna be 13 years old this year and SVG will be astonishing 25 years.

And no, the "state of the art" is not really changing, unless you're going for non-market-tested technology. But that's you, that's not the market, that's not what people are hiring for, and that's not even what's getting stars in Github. New experimental projects are not "change".

The "state of the art" is still React/Vue/Angular, perhaps with SASS or CSS, which is from 2006. Even Webpack is 10 years old next February! And only now it is getting serious competition. Typescript is still 100% optional but is 11 years old.

The meme that "Javascript changes too much" was already old and tired in 2015. In 2024 it's absurd.


No the meme is frontend changes too much not JavaScript changes too much and that meme is still relevant and will be relevant for a while.

Heck you can argue for how HTML and JavaScript are 20 years old!! Wow that means front end hasn't changed at all for 20b years! Come on man.

Anyway my overall point wasn't even about what's changed. My point is that these are all awkward apis to use to develop a windows style UI.

Even if you think they are old, these frameworks are bending and adjusting an underlying layer to do something it wasn't designed to do in the first place. Hence the awkwardness.


I'd be happy to discuss specific changes in good faith, but "Wow that means front end hasn't changed at all for 20b years!" is a gross misrepresentation and dismissal of my arguments.

I will maintain that the pace of change is not the same as you portray. Definitely not when it comes to professional frontend developers working in the industry. Blog-oriented-development or experimental niche frameworks that reach top of HN don't count as "industry" yet.


It's not a gross misinterpretation. I'm sorry, but a huge portion of the evidence you've stated was simply the ages of certain technologies and using that as invalid evidence for your arguments. I've clearly presented evidence to the contrary and you simply call it a gross misinterpretation without even providing a counter argument?

Your job is to prove why ages of technologies is relevant to your argument. If it's not then the only thing you can do is admit how that part of your argument is fucking baseless. You may be happy to discuss other things with me but until you admit or prove me wrong on this point there is zero further discussion about anything. Just walking up to someone and telling them they're wrong is useless. When you say gross expectation I expect some evidence to back that shit up. If not then you can just leave.

That being said I don't think I'm in the mood discuss anything with you. Let me be clear, any response you make to me after this will be illogical because I won't care for it or respond and it will be a complete waste of your time. We are done.


My point was simply that the technologies we use are established, and haven't changed much. The age matters, because the current dominant players have been dominant for longer than jQuery was at the top.

Your counterpoint was instead that React changed a lot, but I counter argued. You are free to disagree with that, of course, but instead chose to answer with "Come on man!!"...

I understand that it might seem overwhelming to see lots of "new things" here at HN and other sites, but the reality is that those things are pet projects or new incumbents that haven't been adopted at large by the industry, if at all. In reality, movement in frontend has been slower after 2015 than it was in the 10 years before.

And sorry but you can't preemptively call my response illogical. This is not cool.


Hey I'm not reading your response. As I said, I don't want to talk with you, so you are wasting your time irrationally talking to me. This conversation is over. Please leave.


You are overlooking a massive point that invalidates your concerns from a homebrew developer's POV: it is _easier_ on the mind to make apps using low-code graphical interfaces than with full-code.


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


I keep seeing this complaint but I have never reproduced it locally. VSCode runs at a buttery smooth 120hz on my MBP. What are you doing that causes such poor performance?


It's extensions. Some of them can drag a machine to its knees, with unbounded CPU usage. The worst is the C++ extensions. Gets stuck at 100% CPU if you open a file it doesn't like, which is most of them.

VSCode with no extensions is very fast and light. VSCode with 30 extensions you've accumulated? Not so much.

I think that's why you see such conflicting experiences - people have different extensions.


I think I have like, 50 extensions though not all of them are active at the same time (that's how vscode works I think) and I don't really see the lag. I have a high refresh rate screen, I'm pretty used to differentiating between laggy and non laggy graphics, etc and still nothing stands out. Maybe some extensions are resource hogs but I think vscode provides stats about extension resource usage and how much an extension slows down the editor so people can easily check what is causing their slowdowns.


Yeah, that god damn cpptools intellisense scanner seems to grab one core and peg it for 10’s of minutes after deigning to break an include. I don’t get what it’s doing in there that it can’t at least get spread out over more cores; as-is, it spools up the fan because you’ve got one cpu melting while the rest of the processor is just chilling.

I absolutely love vscode and think all of the people complaining about it being sluggish are ridiculous, but the cpp extensions really are genuinely annoying.


I regularly must sit and wait for vscode to catch up rendering the text I just typed. I suspect the main culprit is the vim extension, but unfortunately that's one of the few extensions I cannot go without.


Ah yes the vim extension is known to be an issue. IIRC the problem is it works by hooking into every key press and blocks VSCode in a way that no other extensions really do.

Actually I think Rust analyser had a "smart enter" feature that worked in a similar way and was similarly slow.

Basically if an extension overrides typing then it's going to be slow.


> All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window.

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?


From an "interfacing with the OS" point of view, a game engine interacts differently. Most desktop apps ask the OS "please render this text here, with this font" and the OS takes care of that. A game engine just asks the OS "here is a canvas I have drawn, please just put these pixels on the screen". The OS doesn't know that a chunk of pixels is text, so you can't select it, copy and paste it, or screen reader it by default.

This is the same difference between an system like Flutter and native App toolkits (I'm going to talk about Flutter because I know more about it). It has massive advantages on portability - Flutter rendering is very predictable on different phones because the only thing that can vary is screen size. The subtle variations between OS versions and phone manufacturer UI skins don't screw things up.

There are downsides: You need to implement all the common stuff that you'd normally get for free. This includes native look and feel - Flutter has to have all the Android and Apple widgets. It also includes text rendering accessibility, etc. etc.


To give an example comparing a text field in a native OR webview-based macOS app with a hypothetical Godot-based one, the Godot version would need to reimplement (or likely just omit):

- Copy/paste

- Emacs/readline keybindings (Ctrl-A, Ctrl-E, etc.)

- User's preferred text size and font as selected in System Preferences

- Spellcheck

- Nice features for non-latin text (e.g. built in pinyin keyboard)

- Crisp text rendering

- Dictation support

- Screen reader support

- Autofill

- Automatically updated with OS updates (e.g. HiDPI, all Java UIs had looked almost-native but were now stuck looking pixelated)

- And hundreds more features I'm forgetting...

This is all possible to do in Godot (e.g. the Godot Editor does a lot of these) but with a lot of work required. It's completely built in to any native or web-based text field and doesn't need any additional work.


Think of it like the difference between building a bicycle by taking existing parts and assembling them, vs just starting with raw materials and fashining a bicycle. If you use the pre-built seat that has a spring (suspension) on it, then you get that "for free." If you're assembling from scratch, you either have to build a spring (not very easy) or go without one. For many bikes, it's going to be without and for the ones that do it, odds that the spring will be as good as or better are low.

With a game engine the OS is basially handing you a blank canvas and telling you to draw what you want. With a GUI toolkit like GTK or Qt, the "OS" is handing you a bunch of pre-made parts and you get to arrange them on the page how you like.

If you're writing a game, the former is obviously better. If you're writing a standard application, the latter is usually better. By "better" I mean higher quality output, and less work to construct.


> I don't think Godot is inherently more performant for any random UI than Electron

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.


Adobe Air, anyone?


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

[1]: https://github.com/mbrlabs/Lorien


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/

[2]: https://megasploot.github.io/DungeondraftModdingAPI/


To add to the list, Pixelorama[1] is a pixel art sprite editor built on Godot.

[1]: https://godotengine.org/showcase/pixelorama/


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.


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


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 cons?


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?


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.


There is some ongoing PR, so it might come at some point :

https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aop...


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.


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.


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.


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.


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.


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.


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.


I RDP or VNC into VMs that run without a GPU all day. It's very much optional for 2D, at least.


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.


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.


> 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


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


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


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.


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


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


Have you heard of AppImage?


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.


Sounds like you're describing Flutter.


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.


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

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.


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.


> 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


.NET is licensed under MIT[0]. There are additional concessions[1] regarding the code that used to be proprietary specifically to make all the Mono bits to be legally sound.

[0] https://github.com/dotnet/runtime/blob/main/LICENSE.TXT

[1] https://github.com/dotnet/runtime/blob/main/PATENTS.TXT (I think there was another document, please post the link if you remember which one)


As I pointed out in that thread, I wasn't able to track down the license of all required DLLs for the binary distribution.


I think it’s an imagined problem and in practice no one has it. Just stop worrying and start deploying :)


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

I think the functionality for multiple windows was added before this release but here's the 4.1 notes that you can open the code editor/other stuff in other windows: https://godotengine.org/article/godot-4-1-is-here/#editor

I just tried it and it seems to work.


The Godot IDE itself is a "game" as in it is entirely built using Godot APIs. Makes me wonder if it would actually be a good environment to build portable business apps, sort of like a modern Visual Basic.


It would have all the issues of Flutter (non-native widgets, accessibility, etc) without the focus on these specific kinds of use cases.


Only nerds care about non-native widgets.


Native widgets come with a bunch of accessibility and localization features that are typically missing from naive custom widgets.

A native English speaker with normal vision might naively assume that they could reimplement a widget that's just as good as the native one in less than a week, but the result will be awful for anyone who doesn't match that description.

If you're building with web tech accessibility and localization are easier to add to a custom widget (though they do still require thought), but this is Godot, not Electron.


I've read comments like this for years. But without concrete examples it doesn't stick.


And people with disabilities.


Accessibility can be implemented for third party GUI toolkits.

Qt: https://doc.qt.io/qt-6/accessible.html

Web: https://developer.mozilla.org/en-US/docs/Web/Accessibility

Even immediate mode toolkits can do it: https://news.ycombinator.com/item?id=33859697

Accessibility is not a reason to use first party widgets. It's a reason to use widgets with good accessibility support.


In theory, in practice the myriad of devices and software is rarely tested or works properly beyond official mac and windows interfaces, and maybe gtk and qt if you're very lucky.


Related: Grey Hack is a fake OS, Network, Internet in a multiplayer game where the objective is to hack (including each other). It simulates many basic functions quite well (you can steal files, place files on other computers, install software, run commands from a command line, including imitations of many tools). You can also write your own programs.


When will someone go all in and release a hack game with hundreds of emulated real little servers of various operating systems and vulnerabilities?


Some time ago, I found a site that provided different variants of VMs you could download which contained exploits you could utilize to pwn the machines. There were also walkthroughs and guides available to teach you how to break in.

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?


There is [vulnhub](https://www.vulnhub.com/). There was another one that started with an “e” (it had Linux and code challenges too (e.g. here is the C code, exploit privilege escalation)). I remember a few years ago the site went down and a mirror was stood up under a different domain. Don’t have those links unfortunately.

Edit. Found it:

- What it used to be: https://web.archive.org/web/20180202211058/https://exploit-e...

- Mirror: https://exploit.education/

- Also can be downloaded at vulnhub: https://www.vulnhub.com/series/exploit-exercises,11/


I’ve always thought it would be interesting to try something like that for a LARP.

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.


That's what CTF at Defcon is like!


At a certain point on the realism continuum, just get rid of the gamey parts and deliver someone a set of VM images that they have to boot up and break into.

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


> Maybe that's actually what Hack the Box is, mentioned in the sibling

Hack the Box hosts the VM for you on their servers (and you connect to a VPN to get access), but it's effectively that. They release a box every so often (roughly monthly?) and users compete to collect the user/root flags.

They also have a rotating selection of past boxes (and I think you get access to all of them if you pay them), so it's kind of like an "on demand" CTF.


Isn’t hack the box already itching this?


Yeah, my employer does that. We call it "infrastructure". /s


This might still be useful in the real world. Think movie industry, where having a mock OS for showing characters doing computer things is practically a trope in its own right. I was recently in a discussion with some fans of the movie Hackers, in which one of them asked what OS they used in the movie. My reply was to the effect of, what every movie in the 90s used, which was basically Mac OS with fake UI elements cobbled together in Macromedia Director (or Flash in later films).

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.


This just makes me yearn for a UI-centric minimal compilation mode for Godot. It's such an enticing target for GPU-rendered UI, and there are even some excellent libraries and plugins out there for making components that are useful in engineering or data analysis!


You can disable a lot of Godot's features when building the engine from source [1]. Not sure how much you can save while keeping most of the 2d/3d components, but it should be possible.

[1]: https://docs.godotengine.org/en/stable/contributing/developm...


Pretty sure that already exists. You can choose which Godot modules you compile via the custom_modules flag. We, for example, ship a tiny wasm for our 2d Godot web games.


Godot is a great sketchpad for these things. One time I was at the airport for a flight, so I wrote a quick-and-dirty notepad for the Russian pencil-and-paper game Virus War (“Война вирусов”) for my eInk tablet that my partner and I could play. It was just a grid with tappable buttons in varying states, but I was able to get a playable prototype ready for our flight.


This reminds me of a time circa 2005 where "Sub OSes" were somewhat popular in the GameMaker community. Seems that given enough time someone will try to make an OS-like interface in a given game engine.

It was a great way to understand UI and usability paradigms beyond building game mechanics.

This definitely triggered some pleasant nostalgia for me.


Nice to see someone else who also remembers those.

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.


Do you have any material online on Tiagix OS? I can't seem to find anything from a quick Google search.


I think there's a build of an older version of it on the YoYoGames archive. The archive didn't save the screenshots that the original website had, sadly.

I also spent a long time working on a very large update which I might have archived somewhere locally but never shared it online.


Looks like there's still some activity in the "scene" all these years later.

https://forum.gamemaker.io/index.php?threads/gm8-subos-proje...


Also there are some in browser operating system as well, typically they have OS UI shell and applications. Unfortunately I forgot their names.


Yes I remember the same for The Games Factory 2/Multimedia Fusion


> Note: GodotOS is not actually an operating system, it's an application with an interface resembling one.

...actually, is GodotOS any less of an operating system than early versions of Windows?


I remember when Notch was playing with this space game with a slimed down assembly language he created. He stopped working on it unfortunately, but I still think there's a whole potential genre of hacking on a game. Not a "press F" to hack, but a legit log into this system, get/change whatever. Having a legit in-game OS seems like a good step forward.


For the curious: https://en.wikipedia.org/wiki/0x10c

https://web.archive.org/web/20130905082541/http://dcpu.com/d...


Ah yep, that's the one I was thinking of. Really disapointing he never released it.


Factorio has a mod where you can program electricity circuits using assembly, I forgot the name. You place a "computer facility", connect to the signal network, then open a terminal to start programming.

It's pretty cool because factories can be very complex, giving it real utility. And you can communicate over the wire with fair sophistication using items as signal symbols. The clock speed of the devices was limited to a few instructions per game tick.


At what point does it start looking too much like your real job? Zachatronics game Shenzen had that problem for some friends of mine that do chip design professionally.


Bitburners does a pretty good job. Its an idle game with fairly limited "OS" emulation, but the best solutions require real thought and programming knowledge.

You'll be writing scripts to scan the net for open ports, automatically "hack" into them, then globally balance allocate memory between all of them according to certain parameters to make the hack the most "profitable". You'll be writing elementary socket communications, building scripts to feed analytics back to your home PC, even alogirthmic trading in a fake stock market. I had fun with it.


https://store.steampowered.com/app/716490/EXAPUNKS/


It's more programming than hacking but you might enjoy TIS-100

https://www.zachtronics.com/tis-100/


From the screenshot:

> GodotOS is a fake operating system

Is it fake, though? Does the term "operating system" imply the level of hardware it's running on? Otherwise, even if it's running on top of another OS, it's still an OS.


It's a fake OS in the sense that it's actually an application, not something that can be ran as an operating system like Linux or Windows. I've been a bit careful with my wording when advertising this, I wouldn't want to give the wrong impression.


Would "desktop environment" be a more appropriate description?


Absolutely, but I feel like it's a technical term that might be hard to understand or advertise. When I explained the project to my non-technical friends before showing them, I told them "Ah, it's like an operating system" and they generally understood what I'm going for.


Is it a desktop environment in the Gnome or KDE sense? I didn’t see any third party programs in your trailer video so I guess you can only run your built-in “programs,” right? So I would say it is not really a desktop environment… I’m not sure what the technical definition is, but I must have something to do with acting as an environment to draw other programs.

Calling it a fake OS was, IMO, s great choice for avoiding confusion. Maybe something like Concept-OS or Desktop Environment Mockup could be good names if you want to be fancy.

How hard would it be to include a terminal emulator? You’d get a lot of functionality for free, there!


Desktop Environment is already taken by systems like Gnome and KDE. This is more like a mockup. The “concept car” of desktop environments. It is quite neat.


Yes


Sounds like a shell https://en.wikipedia.org/wiki/Shell_%28computing%29#Graphica...


Is anything that needs a kernel to run also a fake OS? Or drivers/bios/etc.


Is Pharo/SmallTalk/Interlisp a fake OS?


I feel like operating system implies the existence of a kernel


Robot Operating System (ROS) is also an operating system, but it runs on top of computer operating systems like Linux and MacOS, and is focused on supplying the services, build toolchain, and communication standards/paradigms that are useful for implementing a robotics system, much as Linux (and its distros) are focused on providing that for a general computing environment.

In any case, it's clear that the project under discussion here isn't really any of these things is rather a system shell/GUI/launcher. But calling it an "OS" falls under the fun tradition many of us enjoyed in our youth of trying to recreate our own Windows in whatever was our programming platform of choice, and thinking that was what an OS was.


An application that spawns processes/apps/modules, controls them and lets them communicate back to the application for some service is also, in a loose sense, an operating system.


That seems a bit too loose.

Doesn't that apply to IDEs that implement the language server protocol, since they spawn language servers and communicate with them?

And servers like Apache that spawn child processes to handle requests?


Apache supervises tasks in the form of threads and subprocesses, including managing memory in the form of pools, so yes, it's doing some of what an OS would do. It isn't, on the other hand, providing abstractions to hardware, and that's what I think of when I hear "OS". It's not really a cut-and-dried thing though: modern web browsers are like 90% of the way to being full-blown OS's, even down to abstracting hardware in the case of things like WebGPU, but they still rely on a host OS to bridge the connection and do the actual bit-banging required to make it work.


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 (3d filesystem representation).

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? I know I've been nervous that I might have a bug that does something destructive and that is why I've been working on my ci/cd pipeline and unit tests but am just curious.

Either way, it has been awesome watching the explosion of creativity happening in Godot land. I compile daily and watch the commits and see such vast improvements being made all the time. It's a great engine with first class c++17 support with GDNative and modules, and I truly believe the future of gaming (and many other things) is FOSS. My only meta-wish is that the engine was GPL instead of MIT, but luckily that doesn't stop me from releasing my stuff built in it as GPL.


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


With OS. functions (including OS.execute) you don't need any third party things or GDExtensions from my point of view. You might check it out if you haven't. I am working on a real file browser in 3d and execution launches applications natively in linux for example. It's not launched "within Godot" per se.

As for the GPL thing: that's exactly the point!

Wish you the best in future Godot dev.


I would love a write up on design philosiphy. I'm currently learning Godot coming from web dev, and finding the distributed business logic impossible to organize. I just don't know who, what, or where business logic should be.

My urge is to lift logic up to the parent of any group of interactions, and let nodes just be renderers. But I understand that is absolutely not the design philosiphy of Godot, and probably won't scale.


It's impossible to be sure without knowing your programming experience in general across sectors, but it sounds like you are unused to the paradigms of game programming in general, which is centered on logic executed per-frame rather than per-flow (like in business applications, which is where the concept of "business logic" comes from).

The default approach in game engines is to bind data including state to an actor, then have define per actor, in a given state, how it modifies its own and other actors' data over a frame (usu. processing user input as necessary), and how it renders to the screen. This is what game engines are designed to make easy, by providing something like an "Update" and "OnDraw" virtual functions you fill in for every element in your world.

Inevitably every application needs to have a few "directors" who need to take care of business that can't be isolated to an individual "actor" or per-frame state manipulation, and these are usually structured around async-awaits, callbacks, is a thread handler/dispatcher. But if you go overboard with directors, actors that operate like directors, or actor-director interactions, you're inviting trouble in game-engine-land.

There are some alternate paradigms like "entity component system" and entirely callback-driven event-driven game architectures, but they tend to never exist in purity without the actor-update model.


Ironically, early days Java Applets had you painting things on a canvas with a similar event loop. I think Flash also operated this way.

I almost think if someone were to build applications with Godot (or another engine) that you would need to mentally translate from something like React components and their data to the actor/sprite+state in an event loop model.

For example a todo list in Godot might have an actor that is the checkbox with some text next to it and the state of checked/unchecked, then allow the user to click something which generates more of these actors/sprites dynamically. I think where it really becomes cumbersome with a game engine is no real organization of a scene exists without you explicitly laying out x,y pixels. There are concepts of "relative" but common application concepts of pagination, etc. would be hard to pull off in a simple way in the code I would imagine.


I certainly am unused to it! maybe I’ll ask some advice:

I’m trying to build a circuit simulator. It’s got two main problems to solve: placing and connecting drag and drop electrical components, and the simulation itself.

How would you go about this? The existence of the sim means there’s already guaranteed to be some global manager that understands the current layout and can compute from it. What I don’t know is if that means most things should be handled that way.

Should components be heavy, and make their own changes to the tree, and then let manager read the tree in and build up its schema that way? Or should components be just emit everything to the manager, who then can both build the tree and a state representation.

The second feels cleaner for this use case, but it feels not standard for Godot. Maybe it’s a bad project to start with.

I did build a basic platformer too, and found the distributed logic much easier to deal with there.


> placing and connecting drag and drop electrical components

This is where game engines are annoying. You have to do "collision checks" between your cursor and any points of interest, like a slot or a grid or a connection. Usually in a 2D use-case like yours, you can just do a geometry condition (if component.x > slot1.x && component.x < slot1.x + threshold...), especially while your UI elements are regular shapes. Engines are fast at doing lots of native collision checks in 3D and with irregular shapes too with an engine-specific "collider" for each element, as it's expected to do collision checks for almost every visible actor in every frame in a game.

> and the simulation itself

Depending on the eventual complexity of your circuit simulator, there are pros and cons to different approaches. My undergraduate electronics degree is fading from memory so I might not have the best advice here.

A purely node/actor-based computational simulator is one approach, which reduces dependency on the global manager with knowledge of the layout or handling of the computation. You have to define how each component responds to charge at its input nodes, and manipulates charge at its output nodes, ie, define its response curve in terms of charge. You just have to work with the differential time-equations for computational analysis of electric circuits, not the closed-form analytical ones. ie, substitute I with dQ/dt (charge over time) everywhere, and in every "update" iteration (or "tick" or "frame" or whatever your engine calls them) multiply the differential equation by timeDelta (every engine provides timeDelta as the time elapsed since the last frame). I would give this method a try scoping the project for very simple components (maybe just DC power source, LED, resistors, connector junctions) that can be sized to a grid of discrete sizes.

This can however feel like rediscovering electricity from first principles because traditional circuit equations usually don't work with charge or with time, since they're defining the steady state behaviour.

If you would rather work with traditional steady state electronics formula for each component type, I think your second solution is a decent approach, "passing the result on" from one node into the next (which is the same as making changes to the tree iinm?). Technically using the steady state equations renders ticks irrelevant, other than updating to reflect any changes in the circuit, or if you have time-dependent component behaviour (like an AC signal or an inductor), but that's still a nice feature to have.

I think you should try avoiding reliance on a global manager for anything that goes on in the simulation as much as possible, because I sense you will tend towards "centralized application logic" if you allow yourself that luxury. The whole point of game engines is to break down your logic into different actors that interact with each other, and a simulation is exactly that.


Yes it will scale.

"Parent of any group"

"Business logic"

Are just concepts you made up in your head.

Those are just nouns your using. They don't really mean anything.

You design your abstractions, you design your scene trees, such that you create an abstraction level that represents your "business logic".

Ie, in our games, we have a FriendsPanel which has a script that will render your friends list. It exposes it's dependencies: a FriendRow packed scene, and a reference of which nodepath to add the FriendRows to.

The game itself, well, the "business logic" will be different for each style of game and style of developer. I'm 10 years deep in indie game dev. My advice is to just fucking send it. My code now is pretty good, but gameplay code tends to be complicated AF and usually is huge procedural blocks. Resist your urge to modularize gameplay code. Your years away from being able to do that. Copy + Paste is a better modularization technique than whatever gong show abstraction your thinking of anyways.

(The best gameplay abstraction code I've ever seen is basically object type based collision response handling, a system like this is great for many games)

Your urge to refactor shit is your brain trying to do something that will take less calories than solving the problem of "why is this game not fun". It's procrastination.


Coming from web dev to Godot was a bit wonky for me and digging into some Godot dev patterns on YouTube and elsewhere went a long way to help me wrap my head around the question of like… “where does this logic/state/etc live and how do I access/use it where I need it?”


The fact that you're playing around with a game engine and using phrases like "distributed business logic" tells me you have a long road ahead of you.


I've been thinking about making a cross-platform mobile app but don't want to think about react native, touch javascript, or fiddle with xcode any more than I have to.

Is it accurate to think that I could instead use godot to create a cross-platform app to eliminate complexity from react native while creating something that is performant/native across ios/android?


I’ve worked in both Godot and React Native. I wouldn’t say you are eliminating any complexity.... You are just trading one UI system for another. UI by its nature is complex and requires a lot of “code”. In the Godot case you might be doing less coding in the “typing letters on a keyboard” way, but you still need to figure out the UI controls and fiddle with the settings in the properties panel until you get it juuuust right. The final product is still saved as code, in tscn scene files.


Would be fun if game engine editor environments took on the UI paradigm of an operating system like windows. So that instead of going to the File menu at the top of unreal engine to open the blueprint debugger, you navigated the start menu to find the program.

I’ve reflected to myself so many times that UE4 feels like an operating system, would be fun if in the future it actually was ha


Eric Lengyel's C4 engine takes this approach.. it's a bit interesting

https://c4engine.com/wiki/index.php?title=Quick_Tour


I think that the Godot UI editor is written with Godot, so it should be possible!


This is great. Would you recommend Godot for prototyping UIs, in general, over HTML/JavaScript?


Short answer: Yes!

Long answer: I recommend Godot for rapid prototyping and creating desktop applications, but not necessarily for web app development. The biggest blocker is that Godot 4's export size is quite big compared to web standards, roughly 35MB uncompressed and 7.5MB compressed. The web version of GodotOS is 7.8MB, which may be too big for professional use.

Godot is fantastic for making quick prototypes though. The editor is very quick & intuitive once you understand the core concepts. It's also a fantastic tool for creating cross-platform desktop & mobile applications, some professional apps have been designed with it.[0]

[0]: https://alfredbaudisch.com/blog/gamedev/godot-engine/standal...


Nice. Yeah, I was thinking as a rapid prototyping tool. There's a big gulf between Figma and something like a Godot prototype. The former can give you high fidelity in look, but not in feel (interaction).


I guess you are aware, but Godot can be compiled to JavaScript: https://docs.godotengine.org/en/stable/tutorials/export/expo...


> silksong never.png

Why do you have to hurt me like this


I guess that "a desktop that is minimalist, distraction-free, and aesthetically pleasing" means Windows 2000 with transparent backgrounds.


https://simulavr.com/ was coding a VR desktop with Godot.


Looks great! I know there are a bunch of games that use this kind of setting (fake OS) as the main mechanic. Her Story comes to mind [1].

1: https://store.steampowered.com/app/368370/Her_Story/


Hypnospace Outlaw is the absolute MVP of this category. That game is a trip.


Thanks for the mention! I remember playing a bit of the previous game from the same author (Dropsy!)


This is a pretty cool prototype for something I'd considered Godot for: a GUI for a device running embedded Linux. In that environment, you want the least bloat but some decent development tools so you can iterate reasonably fast. That's not a widely-available combo.


Ha! This is really cool

I'm really impressed that you were able to create this in Godot. Looks like it's all GDScript too. Nice

You even tucked away a pong game in there.

What do you think of Godot? I've been thinking of switching to it after I finish working on my Unity project


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


This is sadly just a nested compositor, it seems like it does not implement any new Godot drivers…


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.


Thank you for making this! I’ve been dissatisfied with the options available for making local GUIs and curious about what could be done with game engines. What was it like working with the UI layer of Godot?


Quite fun. I find it a lot simpler and more intuitive than other UI frameworks I've worked with (especially front-end webdev), but I understand it's very opinionated. Once you get accustomed to using Control nodes in Godot (that's what they call UI components), it becomes super easy to rapidly prototype and design anything you'd like.


This is really neat!

I almost wonder if this could be adapted into a “real” desktop environment, as in “competing alongside KDE or Gnome”. I have no idea what’s involved with doing that but it it would be cool if you could.


This is great, actually thinking of building something similar for a game I'm working on, but other way around really. OS in game instead of game in OS. :)


This is neat. I always wondered if it was possible or if anyone has made a fancy UI for instrumentation / dashboard using a game engine.


Have you thought about turning this into a linux desktop environment? It wouldn't even be the first Wayland compositor using Godot.


Very nice. I wish it would also work on mobile. The initial screen showed up but "clicking" on folders does not cause any action.


I played and finished Super Bit Boy. :D Reminded me of the game "Thomas Was Alone", that was nice. :)


We at a stage where desktop environments become faster than the OS they run on (ahem... Windows).


This is awesome!

I'd love to boot this up and see how it runs on a Quest headset


super bit boy made me instantly younger by about 15 years. thanks!


More like GodotDesktop


Dang! I just realized github no longer works on my old macbook running firefox 78.15.0esr (64-bit).

BigTech wants me to buy a new macbook or switch to chrome.

Edit: it's actually no laughing matter. I'm pretty devastated. :-(


The current FireFox ESR version is 115.6.0. Extended support for 78.15 ended in 2021.

It's weird that your first inclination is a new computer or chrome. Those are two very different things, and neither is necessary.


... or to just update to a newer version of Firefox.


The performance is really nice, I kinda love it.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: