101–110 of 127 posts
Why do software engineers care so much about TUI? I really don't get it. I love a good command line program. But TUI just doesn't appeal to me.
Why do software engineers care so much about TUI? I really don't get it. I love a good command line program. But TUI just doesn't appeal to me.
There isn't much obvious benefit in using TUIs, but writing TUIs has a big upside: it's easier in most ways. It's trivially cross-platform, you don't have to make pixel-perfect GUIs (because it's impossible), you don't need icons or graphics (because you can't show graphics), etc.
Many people here mention SSH as one motivating uses for TUIs. It's a shame that we don't have standardized HTTP forwarding over SSH that would work as seamlessly as X forwarding can work.
Earlier quoted context omitted.
Because I don't need a resource-heavy GUI for something as simple as a music player.
GUI is not intrinsically any more resource-heavy than TUI; ultimately you need to render stuff on screen somehow and get user input, and going through tty layer just is extra bloat.
Specifically when dealing with remote environments where you connect to through ssh anyway it is really awesome when some things can be done through a nice TUI. In that context a GUI would actually be more resource heavy considering that it likely will be web based with much more client side processing happening for the GUI.
Earlier quoted context omitted.
Are there any libraries in place which can normalize all emojis down to a single symbol?
It doesn't matter; what matters is that both your (terminal-manipulating) program and terminal emulator agree on the symbols widths. Considering that they usually won't (lots of terminal emulators have their own hand-crafted, statically linked wcwidth/wcswidth functions; the readline library also has them hard-coded, by the way), it's quite frustrating.
Interesting that they're hiring. I'm curious how they plan to make money from a TUI framework
Earlier quoted context omitted.
I don't agree that React is FRP. FRP is a generic solution that builds data-UI synchronization around data, and assumes that incremental UI updates will be written in UI code. React puts data-UI synchronization code inside UI components and provides an Immediate Mode-like API to avoid writing incremental updates in UI code.
In your world, the incremental UI code lives in the react library, and react applications aren’t UI code, they’re just FRP data transformations.
[0]: https://xdsl.dev/ [1]: https://marimo.io/
Many people here mention SSH as one motivating uses for TUIs. It's a shame that we don't have standardized HTTP forwarding over SSH that would work as seamlessly as X forwarding can work.
We have -L though, isn't that kind of what you're looking for?
Sketching out this idea, what I'd want is that ssh would set some standardized env var pointing to unix socket (analogous to $DISPLAY), and applications when starting up should pick that up. That should trigger applications to start listening on another unix socket (instead of tcp port), and notify ssh through the socket pointed by the env var. Upon that notification, ssh should set up new tunnel and open new browser window pointing to the tunnel.
Nothing about that is technically particularly difficult (I'd say its almost trivial), but it'd need standardization to be truly useful.
Of course that would lead to not recognizing weird color codes and so on, but perhaps there could be a plugin system, where one could add a plugin that transforms color codes and such in the output into XML tree representation.
And then one could perhaps log the whole thing in various formats: Only visible text with colors, without colors, whole XML tree, or as JSON, or whatever other format it translates well to. Also could be extended via plugin.
But bare bones it merely treats everything as text.