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

221–230 of 292 posts

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

#221

Post by whstl »

forrestthewoods wrote: post #205
whstl wrote: post #203

Earlier quoted context omitted.

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

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

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

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

#222

Post by johnnyanmac »

forrestthewoods wrote: post #129
whstl wrote: post #107

Earlier quoted context omitted.

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.

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.

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

#223

Post by forrestthewoods »

whstl wrote: post #221
forrestthewoods wrote: post #205

Earlier quoted context omitted.

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

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…

I will grant you that Accessibility is not handled well.

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

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

#224

Post by mikaelsouza »

bufio wrote: post #75
ladberg wrote: post #58

Earlier quoted context omitted.

This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. I also don't think Godot is inherently more performant for any random UI than Electron is. It happens that most Godot apps are performant because they're made by the type of people who want to use videogame engines and thus…

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…

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.

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

#225

Post by mardifoufs »

alpaca128 wrote: post #173
then4p wrote: post #90

Earlier quoted context omitted.

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://gi…

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)

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

#226

Post by mardifoufs »

IshKebab wrote: post #186
fauntle wrote: post #149

Earlier quoted context omitted.

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.

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

#227

Post by lolinder »

IshKebab wrote: post #183
jeremyjh wrote: post #88

Earlier quoted context omitted.

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.

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

#228

Post by whstl »

forrestthewoods wrote: post #223
whstl wrote: post #221

Earlier quoted context omitted.

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…

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.

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

#229

Post by depressedpanda »

IshKebab wrote: post #186
fauntle wrote: post #149

Earlier quoted context omitted.

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