Hello Will,

I just wanted to say that rich is a great tool that I'm very appreciative of, and __rich_repr__ is a godsend for debugging datasets without vomiting an overload of text into my terminal. Or consolidating spark's awful, multi-language stack traces. Excellent work. Textual is a lot of fun too, and I've been looking forward to this update. Thank you!

Cheers. Rich repr has become essential in my workflow as well. It's one of those small quality of life things that makes for one less thing to think about.

Could you elaborate on how you use the tool for the two purposes you mentioned?

Of course.

I use __rich_repr__ to make object representations more succinct[1].

This can also be used to make pretty custom exceptions. You can also use rich.Console.print_exception to output formatted stack traces, with options for including locals, suppressing certain errors, or limiting frames[2]. Pretty great for spark, which usually vomits a novella upon erring.

Also, %load_ext rich in a IPython shell to pretty print all output, exceptions or not.

[1]: https://rich.readthedocs.io/en/stable/pretty.html#rich-repr-...

[2]: https://rich.readthedocs.io/en/stable/reference/console.html...

Also want to ask about accessibility. It's hard to bolt it on after you've worked on the project for awhile, and if the library catches on you could wind up creating hundreds or thousands of inaccessible applications downstream.

Accessibility is very much on our minds! https://textual.textualize.io/roadmap/

How's the accessibility of these interfaces? I believe you mentioned an intent to target the Web some time ago, implying that Web interfaces could expose semantics to assistive technologies. Is this still on the roadmap?

That's definitely on the roadmap. I'd love it to also work in the terminal, but AFAIK terminal screen readers will just scrape the terminal. What we need is an API to interactive with.

Hey Will! I have been following your journey since the very beginning and I'm rooting for you folks. It's insane how someone decided to fund a project like this, and I'm giggling with glee. I hope you folks go all the way! I can't wait to tell people who look down on Terminal users and tell them "Look, a terminal-first service got funded".

Cheers!

Rich and Textual have completely changed how I develop Python apps (for the better). Even when building full Qt GUI apps, I still use Rich to improve any console / terminal output involved. By far the best (and most featureful) Python library of it's kind that I've found. Thank you for releasing it to the world.

This is a mean upgrade. Bravo.

ps: I didn't follow the latest changes, how is the keybinding aspect ? do you have single keypresses ? or key-sequences ? or even chords ? As an emacs-er I like to have semi-complicated custom keybindings. Anyway just asking, not a ticket :)

If it helps, I cover it in my little unboxing video: https://youtu.be/WLwVnYb5Adw

thanks paul, but this only shows single key binding. I was curious if there were work or future work to support key sequences (Ctrl-x Alt-h v).

We have a binding system that maps keys to "actions". The idea is that they will eventually be read from a conf file, so you can remap keys.

Really enjoyed the file browser demo.

Ever since I discovered the project, I have been wondering if I could wire it up with something like Pyodide to have a Python based interface that could work on the terminal or the browser.

I think that’s their commercialization plan - a hosting service for Textual-based webapps.

Ah dang, that websockets thing would have been useful a month ago for me. I was trying to forward stdout to a scrollable pane - I initially tried textual but the performance was kinda poor when scrolling. Ended up going with prompt toolkit instead because I could get it to work.

Print log to file, then tail -f in another tab/pane.

That's basically what I'm doing, but the scroll performance was not good.

If text-scroll performance is an issue on a computer after the year 2000 or so, your terminal/app/lib is doing something wrong. Even the very atrocious windows terminal performance has been fixed by this point.

This wasn't a terminal issue, this was a TUI issue with Textual.

Edit: actually to clarify - it was probably me using it wrong, but I didn't have any good examples of what I was trying to do.

The work-around I was referring to, doesn't require any software besides a xterm-style terminal and the tail command.

For my own reasons I needed a TUI - I’m aware that part of what I wanted to do could be replicated with tmux and some tails. It wasn’t _just_ logging though, I had good reason to want a python TUI.

Man it looks great these days! Only issue is... it turns out I like using the terminal because I don't have to worry about building a UI, haha.

I would argue all command line tools have a UI, even if it's just a textual one (consisting of command line parameters, maybe a text prompt, or in rare cases even an ncurses interface). When I develop command line tools I always think about the UX the user will have.

Looks neat. Is there a way for this to be used with C++? Seems like a nice improvement on ncurses.

How will you get money to pay the developers?

I just listened to Will on a podcast, and apparently, they're going to package Python apps with a terminal such as xterm.js to solve the Python distribution problem (either as Electron apps or in the web browser), then have customers host their "TUI" apps on proprietary Textual infra- basically a PaaS. He mentioned charging for features like SSO. The library itself would stay free for offline use and you could "pip install" any Python apps that use it.

The company was funded with Venture Capital.