Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ratatui – App Showcase

ratatui.rs

Post reply on HN
Print view View original

231–238 of 238 posts

Re: Ratatui – App Showcase

#231

Post by kibwen »

eviks wrote: post #212
kibwen wrote: post #209

Earlier quoted context omitted.

Text has inherent structure that GUIs don't. The ceiling for GUIs is higher (thanks to standards and supporting frameworks), but the floor for TUIs is higher.

Ok, what is the inherent structure of these two columns and how is a screen reader supposed to divine that structure without the framework telling it that there are 2 headers with the following text? And imagine the layout is space-separated as in cli utils C| Column Wide | o| | l|| 1|2|

Even at the worst case, text can be read aloud and give some indication of what the screen contains. This is absolutely not true for a GUI which could easily just be an opaque rendered canvas. The fact remains: TUIs are inherently legible in ways that GUIs are not guaranteed to be.

Re: Ratatui – App Showcase

#232

Post by eviks »

kibwen wrote: post #231
eviks wrote: post #212

Earlier quoted context omitted.

Ok, what is the inherent structure of these two columns and how is a screen reader supposed to divine that structure without the framework telling it that there are 2 headers with the following text? And imagine the layout is space-separated as in cli utils C| Column Wide | o| | l|| 1|2|

Even at the worst case, text can be read aloud and give some indication of what the screen contains. This is absolutely not true for a GUI which could easily just be an opaque rendered canvas. The fact remains: TUIs are inherently legible in ways that GUIs are not guaranteed to be.

Both false: you'll have NO indication if you read letters from different words out of order! You'll not understand whether 'o' is a value or a continuation of the column name even in the primitive example above, and for anything even remotely complicated it's even worse.

> This is absolutely not true for a GUI which could easily just be an opaque rendered canvas. Are you not aware of OCR? Besides, GUIs have special accessibility tools, which almost none of the TUIs have, so your opaque canvas isn't universal.

> The fact remains:

That's a myth, not a fact, and you fail to establish "the fact" even in the most basic example

Re: Ratatui – App Showcase

#233

Post by orbital-decay »

prmoustache wrote: post #230
orbital-decay wrote: post #204

Earlier quoted context omitted.

Every text editor and most professional apps have elaborate hotkey schemes in practice, though. It's a matter of target audience and developer intent. There's nothing special about TUIs in regards to keyboard driveability, and they're heavily limited in just about every single way I can think of. Which is the main reason most TUI apps are simple and small utilities.

The very nature of being simple makes it so that the amount of hotkeys you have to learn is limited. While most gui ones also have hotkeys, most people only remember a tiny selection and have to rely on navigating menus and dialogs to access stuff they can't remember which makes their usage very slow.

It depends on the goal, e.g. software like Maya is built for the world in which the amount of required work makes even average projects intractable if you're slow with your tools. Entire generations of actual masters of their craft have built their careers on being efficient with it.

Menus are also not slow by any measure, they're only needed for discoverability, can be navigated with the keyboard as well, and aren't that different from the menus many TUI apps have (e.g. Midnight Commander). Moreover, there are real novel ideas like Microsoft's ribbon, which basically combine vi-style input and discoverability. Hotkeys is just one way to drive a GUI app using the keyboard, out of many.

Re: Ratatui – App Showcase

#234

Post by OkayPhysicist »

eviks wrote: post #214
OkayPhysicist wrote: post #206

Earlier quoted context omitted.

IMO, the value in TUIs lie in 1) Composability: we've got really good tools for manipulating terminal windows like tmux, :term in vim, etc, whereas the same can't really be said for OS-level windows and 2) As a shibboleth: They implicitly state that they're built by and for keyboard-centric technical users, and thus the wants and needs of keyboard-centric technical users are going to be the valued over the wants and…

1. if you use some external window manager tool, what workflow does tmux/term provide you that OS-level windows with that tool do not? 2. specifically for "keyboard-centric tech users" that's a big fail since the terminal platform is not capable of supporting advanced keybindings presisely because all they do is "target the lowest common denominator" (as defined in 1965) of keybinding support!!! So your cool setup fr…

1. I think the fact that you refer to "some external window manager tool", whereas you know the name tmux off the top of your head illustrates that first point.

2. Again, it's not about the possible capabilities. Objectively, GUI programs contain a superset of possible TUI programs (since your GUI program could be a terminal emulator). It's about it being a shibboleth: I can be pretty confident that the TUI application will have a keyboard-based workflow, and I can be pretty confident that the TUI application will be targeting a technical user base, because those are the only people building and using TUI tools. The "lowest common denominator" in that sentence was referring to the users not the systems.

Re: Ratatui – App Showcase

#235

Post by eviks »

OkayPhysicist wrote: post #234
eviks wrote: post #214

Earlier quoted context omitted.

1. if you use some external window manager tool, what workflow does tmux/term provide you that OS-level windows with that tool do not? 2. specifically for "keyboard-centric tech users" that's a big fail since the terminal platform is not capable of supporting advanced keybindings presisely because all they do is "target the lowest common denominator" (as defined in 1965) of keybinding support!!! So your cool setup fr…

1. I think the fact that you refer to "some external window manager tool", whereas you know the name tmux off the top of your head illustrates that first point. 2. Again, it's not about the possible capabilities. Objectively, GUI programs contain a superset of possible TUI programs (since your GUI program could be a terminal emulator). It's about it being a shibboleth: I can be pretty confident that the TUI applicati…

1. I think the fact that you have nothing of substance and have to read into the fact that after reading your comment explicitly mentioning tmux I repeated that illustrates the point is invalid.

2. but what's the value of a shibboleth if it's not reflected in capabilities??? Why would you care that a TUI app targets "tech user base" if you also know it will be less capable in your 'keyboard-centric' workflow due to platform limitations? And LCD for users just doesn't make sense, what user quality are you min-aggregating?

Re: Ratatui – App Showcase

#236

Post by Zetaphor »

jnovek wrote: post #156
hombre_fatal wrote: post #146

Earlier quoted context omitted.

Also once your workflow is increasingly keyboard based (like when using a tiled window manager), TUIs just make more sense. Every GUI I replace with a TUI is one less flow-breaking obstacle where I have to suddenly reach for the mouse.

I think my low-key long-term goal is to eventually fully eliminate the mouse while still enjoying the niceties of a modern GUI desktop.

Going to shill for the Ultimate Hacking Keyboard here, specifically its mouse-keys capability, which is where I can move the mouse via WASD (or any other binding). I have both the touchpoint and trackball add-on modules, but I still use mouse keys to manipulate my cursor 99% of the time.

Re: Ratatui – App Showcase

#237

Post by [deleted] »

eviks wrote: post #235
OkayPhysicist wrote: post #234

Earlier quoted context omitted.

1. I think the fact that you refer to "some external window manager tool", whereas you know the name tmux off the top of your head illustrates that first point. 2. Again, it's not about the possible capabilities. Objectively, GUI programs contain a superset of possible TUI programs (since your GUI program could be a terminal emulator). It's about it being a shibboleth: I can be pretty confident that the TUI applicati…

1. I think the fact that you have nothing of substance and have to read into the fact that after reading your comment explicitly mentioning tmux I repeated that illustrates the point is invalid. 2. but what's the value of a shibboleth if it's not reflected in capabilities??? Why would you care that a TUI app targets "tech user base" if you also know it will be less capable in your 'keyboard-centric' workflow due to p…

[deleted]

Re: Ratatui – App Showcase

#238

Post by joshka »

ModernMech wrote: post #147
speed_spread wrote: post #138

Earlier quoted context omitted.

That's pretty much how I would expect a UI framework to work. As long as each widget class only depends on the UI base classes the dependencies should be small and grow proportionally to the number of widgets types used by the app. This should also being much less version churn than a big central library including everything.

That's a good point! Some sort of widget framework is important for extensions. But I think my issue is that there are only a dozen included widgets, so very basic things are left to third parties. Most mature UI libraries would include all the basic things, and leave a widget interface for uncommon extensions, not rely on third parties for basic features. With the path they've chosen, it may mean less version churn,…

>This can lead to a situation where some widgets upgrade, some don't, and you're left either on the lower version with unpatched issues, or the newer version missing widgets.

We're fixing that in Ratatui 0.30 by introducing a stable core crate.

Post reply on HN