4 ms·

> I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. The baggage may be

> I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. The baggage may be unnecessary, but I think the key to the success of TUIs is that the terminal’s interaction mechanism is restrictive. To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of. You might end up with something better, but I think it will be very reminiscent of current terminal emulators.

eternityforest 3y ago
I think my ideal terminal emulator would be HTML based. Programs would output HTML, with some special extra tags. If you want a UI, serve a web interface on a random port and embed it in an iframe. You could make app launchers with links that run other apps, and even non terminal people would want to use it.
- wryanzimmerman 3y ago
  I think that’s more or less what this project is working towards: https://hyper.is https://hyper.is
rollcat 3y ago
> To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of. I like to think that software developers are very smart people, and only need a little nudge to steer in the right direction. If all you have is PutRune(x,y,r) and intentionally omit PutPixel(x,y,p), you'll indeed just make a worse terminal emulator. Any decent UI toolkit focuses on a high-level description of the user interface (that's how you get a11y, basic keyboard navigation, etc almost for free), and only provides the low-level operations as escape hatches. This has to be the default route, even for complex or highly customized interfaces (spreadsheet, DAW, etc). I think our nudge could be direct support for terminals as a fallback rendering backend. Best of both worlds: you get a well-behaved GUI app, that you can also use over a serial console (with gradual loss of functionality) if things get dire.

eternityforest 3y ago

I think my ideal terminal emulator would be HTML based. Programs would output HTML, with some special extra tags. If you want a UI, serve a web interface on a random port and embed it in an iframe. You could make app launchers with links that run other apps, and even non terminal people would want to use it.

wryanzimmerman 3y ago
I think that’s more or less what this project is working towards: https://hyper.is https://hyper.is

rollcat 3y ago

> To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of. I like to think that software developers are very smart people, and only need a little nudge to steer in the right direction. If all you have is PutRune(x,y,r) and intentionally omit PutPixel(x,y,p), you'll indeed just make a worse terminal emulator. Any decent UI toolkit focuses on a high-level description of the user interface (that's how you get a11y, basic keyboard navigation, etc almost for free), and only provides the low-level operations as escape hatches. This has to be the default route, even for complex or highly customized interfaces (spreadsheet, DAW, etc). I think our nudge could be direct support for terminals as a fallback rendering backend. Best of both worlds: you get a well-behaved GUI app, that you can also use over a serial console (with gradual loss of functionality) if things get dire.