Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

171–180 of 292 posts

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

#171

Post by jcelerier »

squeaky-clean wrote: post #133
bufio wrote: post #75

Earlier quoted context omitted.

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…

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.

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

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

#172

Post by pests »

rubymamis wrote: post #126
dekerta wrote: post #120

Earlier quoted context omitted.

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/

Looks good. I joined the waitlist.

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

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

#173

Post by alpaca128 »

then4p wrote: post #90
bufio wrote: post #75

Earlier quoted context omitted.

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…

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

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

#174

Post by dataangel »

Gormo wrote: 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 doesn't remotely solve the same problem Flatpak does, you are comparing apples and oranges.

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

#175

Post by oDot »

rubymamis wrote: post #126
dekerta wrote: post #120

Earlier quoted context omitted.

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

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

#176

Post by keerthiko »

koromak wrote: post #166

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…

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.

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

#177

Post by ShadowBanThis01 »

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.

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

#178

Post by whstl »

corethree wrote: post #165
whstl wrote: post #159

Earlier quoted context omitted.

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

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

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.

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

#179

Post by rubymamis »

oDot wrote: post #175
rubymamis wrote: post #126

Earlier quoted context omitted.

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.

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

#180

Post by whywhywouldyou »

koromak wrote: post #166

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…

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.
Post reply on HN