Live data from Hacker News

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

github.com

211–220 of 292 posts

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

#211
post #157

Earlier quoted context omitted.

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…

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…

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

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

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

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

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

#213
post #5
post #3

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.

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

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

#214
post #140

Earlier quoted context omitted.

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.

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

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

#215
post #158

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)

You're probably used to high latency.

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.

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

#216
post #8

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

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

#217
post #142
post #97

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

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

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.

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

#218

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.

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

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

#219

Earlier quoted context omitted.

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…

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

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

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

#220

Earlier quoted context omitted.

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

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

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

Post reply on HN