4 ms·

I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library. What do you think of replacing the 'ren

I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library. What do you think of replacing the 'render' part with something that's more like a generic UI? You could keep the UX the same, yet your app would look like a desktop app (or at least close to it). Trying to fit in the limitations of 80x25 text rendering is cool, but there's nothing in the underlying architecture that of modern graphics display that's predisposed to that, it all ends up as GPU commands. I'm sure you could get most of the way to what I'm describing with just replacing the font/character set with one that renders things like borders in greater detail. Hell, you could even add this as post-processing. You look at the terminal output with cellular automata like rules, and try to render UI primitives fitting that.

joshka 2mo ago
If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your font, missing ability to position borders naturally, interaction with background color, adjustment of size and space of rendered text due to interaction with unicode characters and fixed positioning) ... But in general, going with a fresh new protocol allows you to do a bunch of things semantically that are currently done as pure graphical stuff and that's useful.
- torginus 2mo ago
  I was suggesting something that could be done without changing the protocol itself. From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs. The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11. I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones. Not saying this is a bad idea, but sounds suspiciously like a retread of history. Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves. I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.
  - joshka 2mo ago
    The problem succinctly is when the terminal emulator only sees cell values and instructions it can't do anything more with things. Two really good examples are implementing accessibility well, and scrolling / changing things above the terminal pane without rewriting the whole history.
    - torginus 2mo ago
      What you describe sounds a lot like the HTML/CSS split, with having a separate semantic/display data. I think that's a rather large jump from the 80x25 model, retrofitting that much data sounds like quite the challange. Not sure how you're planning on doing that, can you incrementally extend the current model, or will it require a completely new protocol?
      - joshka 2mo ago
        New protocol entirely. The existing stuff is too baked as having positioning, movement, cells as the unit of abstraction. You need to have that available, but not as the core abstraction level. The core has to be areas, words, layout, etc. Not: "move to 20, 35, start red, bold, print border characters"
        torginus 2mo ago
        Cool, thanks for answering! I don't really want to take any more of your time, is there some place I can read up on this new proposed protocol?
        joshka 2mo ago
        It's mostly something I'm thinking a bunch about recently. Nothing written up yet aside from the above. I'd go read Mitchell Hashimoto's Lobsters interview fora different take and see how that resonates with you as well as the recent blog posts about TUIs and accessibility.

joshka 2mo ago

If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your font, missing ability to position borders naturally, interaction with background color, adjustment of size and space of rendered text due to interaction with unicode characters and fixed positioning) ... But in general, going with a fresh new protocol allows you to do a bunch of things semantically that are currently done as pure graphical stuff and that's useful.

torginus 2mo ago
I was suggesting something that could be done without changing the protocol itself. From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs. The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11. I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones. Not saying this is a bad idea, but sounds suspiciously like a retread of history. Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves. I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.
- joshka 2mo ago
  The problem succinctly is when the terminal emulator only sees cell values and instructions it can't do anything more with things. Two really good examples are implementing accessibility well, and scrolling / changing things above the terminal pane without rewriting the whole history.
  - torginus 2mo ago
    What you describe sounds a lot like the HTML/CSS split, with having a separate semantic/display data. I think that's a rather large jump from the 80x25 model, retrofitting that much data sounds like quite the challange. Not sure how you're planning on doing that, can you incrementally extend the current model, or will it require a completely new protocol?
    - joshka 2mo ago
      New protocol entirely. The existing stuff is too baked as having positioning, movement, cells as the unit of abstraction. You need to have that available, but not as the core abstraction level. The core has to be areas, words, layout, etc. Not: "move to 20, 35, start red, bold, print border characters"
      - torginus 2mo ago
        Cool, thanks for answering! I don't really want to take any more of your time, is there some place I can read up on this new proposed protocol?
        joshka 2mo ago
        It's mostly something I'm thinking a bunch about recently. Nothing written up yet aside from the above. I'd go read Mitchell Hashimoto's Lobsters interview fora different take and see how that resonates with you as well as the recent blog posts about TUIs and accessibility.