A year of building for the terminal • Hacker News Board

Re: A year of building for the terminal

#11

Post by willm » Thu, Dec 22, 2022, 2:59 PM UTC

modernerd wrote: post #7

Has TUI accessibility improved at all? Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.

Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that.

On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.

Re: A year of building for the terminal

#12

Post by sekao » Thu, Dec 22, 2022, 3:09 PM UTC

willm wrote: post #11

modernerd wrote: post #7

Has TUI accessibility improved at all? Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.

Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that. On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.

The browser target sounds neat. Do you plan on running the python in web assembly, or would it be a client/server design?

Re: A year of building for the terminal

#13

Post by samwillis » Thu, Dec 22, 2022, 3:10 PM UTC

willm wrote: post #11

modernerd wrote: post #7

Has TUI accessibility improved at all? Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.

Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that. On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.

I'm intrigued what the planned architecture is for the web front end. I'm guessing WebSocket back to a persistent process on the backend/server?

So all operations happening via the websocket connection. Only the GUI in the browser? I bit like Phoenix LiveView.

This would be a really interesting toolkit for building real-time UIs for remote processes.

Re: A year of building for the terminal

#14

Post by pjmlp » Thu, Dec 22, 2022, 3:10 PM UTC

Looks like I am reading an UNIX magazine article back in 1992.

Re: A year of building for the terminal

#15

Post by sebosp » Thu, Dec 22, 2022, 3:14 PM UTC

I've been playing around rust generative art (nannou) and shader toys on top of alacritty to experiment with other types of visual feedback and other types of interactions in the terminal, not just at GPU level, granted early stages make it convoluted but IMHO still bearable, https://github.com/sebosp/chartacritty

Re: A year of building for the terminal

#16

Post by willm » Thu, Dec 22, 2022, 3:18 PM UTC

samwillis wrote: post #13

willm wrote: post #11

Earlier quoted context omitted.

Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that. On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.

I'm intrigued what the planned architecture is for the web front end. I'm guessing WebSocket back to a persistent process on the backend/server? So all operations happening via the websocket connection. Only the GUI in the browser? I bit like Phoenix LiveView. This would be a really interesting toolkit for building real-time UIs for remote processes.

That's pretty much on the nose!

Re: A year of building for the terminal

#17

Post by ryanianian » Thu, Dec 22, 2022, 3:18 PM UTC

How does Textualize make money?

I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components.

Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.

Re: A year of building for the terminal

#18

Post by willm » Thu, Dec 22, 2022, 3:19 PM UTC

sekao wrote: post #12

willm wrote: post #11

Earlier quoted context omitted.

Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that. On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.

The browser target sounds neat. Do you plan on running the python in web assembly, or would it be a client/server design?

Client / server initially. The app "runs" remotely with a JS front-end.

Re: A year of building for the terminal

#19

Post by goffi » Thu, Dec 22, 2022, 3:19 PM UTC

Textual looks nice. I've been a happy Urwid user for years, can someone with experience with both can do a quick comparison? Urwid development seems stalled (no commit for 6 months). Is it now possible to embed a terminal as a widget with Textual (with Urwid it's possible)?

I'm wondering also how Rich compares to something like Python Prompt Toolkit.

Re: A year of building for the terminal

#20

Post by willm » Thu, Dec 22, 2022, 3:23 PM UTC

ryanianian wrote: post #17

How does Textualize make money? I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components. Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.

We were funded with Venture Capital. Which means full-time developers for the foreseeable future. But its worth pointing out that both projects existed for a long time before funding.