5 ms·

Agreed with your comments, and in fact your comment here: > ...It feels like we're on the beginning of the next cycle a little. First we scattered a bunch of a

Agreed with your comments, and in fact your comment here: > ...It feels like we're on the beginning of the next cycle a little. First we scattered a bunch of apps to see how we should use the internet, then we focused on the browser, now we're scattering some more apps to see which solves our new problems better... Is something that i also have been thinking about myself. I'm seeing the popularity - maybe resurgence - of text based web browsers as well as the Gemini protocol and associated Gopher sites (Capsules i think they're called?) really rise a bunch lately. I'll add that the prevalence of many devs/techies to implement ad blockers, maybe tweak their browsers to avoid running javascript, etc...to represent some shift towards more minimal interfaces for accomplishing their needs. And, simply blanket re-using of old interfaces (some decades old) without some adjustment might not scale to current-day needs in some cases. I myself look forward to these types of TUI experiments (including taking old text-based interfaces and evolving them for nowadays), as i'm optimistic some will stick around.

heavenlyhash 5y ago
I want to see more things like this emerge too. I think one of the bigger barriers is that terminals don't really have a component reuse boundary. What I mean by that is: in the browser, you can always put more HTML inside a div tag, and generally speaking, it's gonna stay within the boundaries of that div tag, and things will compose and it won't be a fuss. In the terminal: what's the equivalent of that? It's possible, and yet not actually remotely pleasant, to make a new PTY/TTY for each component (or each small application that you want to embed within another), and then grab the state of that PTY and replicate it into a rectangular region in another PTY that's bigger. There's so, so, SO much friction in this, though. It also only solves the view bounding: it doesn't solve, for example, the ability to have a copy/paste operation that works on the interior content in a standard way (instead each terminal application solves that itself, usually with some unique bespoke shortcut sequence, because you need _application logic_ to find text ranges since what's rendered to a terminal vs what the logical text state is are usually different). I think if someone created some very basic component-oriented UI system to solve the composition problem -- then kept most of the components as roughly PTY/TTY and TUI concepts! -- it could lead to interesting places that PTY stuff will have difficulty getting to alone.
- russellendicott 5y ago
  I'm actually working on this. Component based over the wire TUI system. It's in a decent alpha state but I want to code and host some more sample sites before I start sharing a ton. Protocol: https://github.com/rendicott/uggly https://github.com/rendicott/uggly Client with gif demo: https://github.com/rendicott/uggly-client https://github.com/rendicott/uggly-client
- deleted 5y ago
  [deleted]
- mxuribe 5y ago
  That's quite a rabbit hole to chase...but well worth it I think. Cheers!

heavenlyhash 5y ago

I want to see more things like this emerge too. I think one of the bigger barriers is that terminals don't really have a component reuse boundary. What I mean by that is: in the browser, you can always put more HTML inside a div tag, and generally speaking, it's gonna stay within the boundaries of that div tag, and things will compose and it won't be a fuss. In the terminal: what's the equivalent of that? It's possible, and yet not actually remotely pleasant, to make a new PTY/TTY for each component (or each small application that you want to embed within another), and then grab the state of that PTY and replicate it into a rectangular region in another PTY that's bigger. There's so, so, SO much friction in this, though. It also only solves the view bounding: it doesn't solve, for example, the ability to have a copy/paste operation that works on the interior content in a standard way (instead each terminal application solves that itself, usually with some unique bespoke shortcut sequence, because you need _application logic_ to find text ranges since what's rendered to a terminal vs what the logical text state is are usually different). I think if someone created some very basic component-oriented UI system to solve the composition problem -- then kept most of the components as roughly PTY/TTY and TUI concepts! -- it could lead to interesting places that PTY stuff will have difficulty getting to alone.

russellendicott 5y ago
I'm actually working on this. Component based over the wire TUI system. It's in a decent alpha state but I want to code and host some more sample sites before I start sharing a ton. Protocol: https://github.com/rendicott/uggly https://github.com/rendicott/uggly Client with gif demo: https://github.com/rendicott/uggly-client https://github.com/rendicott/uggly-client
deleted 5y ago
[deleted]
mxuribe 5y ago
That's quite a rabbit hole to chase...but well worth it I think. Cheers!