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