Textual Blog

When did you try it out? Textual is still at zero-ver but has come a long way recently.

You can build menus and dialogs with Textual with a little effort, but you are correct that there is no explicit builtin widgets for those yet. The type of apps we've been building are more like web-apps than desktop apps, which is why we've eschewed the classic menu bar and drop down menus. But I'd expect to see both in the widget library (https://textual.textualize.io/widget_gallery/) soon.

I don't know what you find unpleasant about async. Personally I enjoy async. But you barely need to use async with the current iteration of the API. See this example in the docs https://textual.textualize.io/guide/widgets/#attributes-down No async or await in sight.

Re "magic methods". I guess you mean the message passing system, which uses a naming convention rather than names defined in a base class. This is because you can send arbitrary messages from one widget to another, and if we didn't use a naming convention you would have to implement your own dispatch method anyway. Yeah, the downside is that tooling might not pick up on `on_click` and similar messages but the convention is staightforward enough.

CSS makes a lot of sense to lay out a TUI. You can get a dynamic layout up and running in minutes, and refine the UI by tweaking a few lines. It lets you iterate faster, and separates the logic in your app from the presentation. Similar benefits to the browser.

I'm not aware of Textual ever…

> Sphinx is basically `grep` for docs. I don't really need that, that's what `App site:textual.textualize.io` is for in DDG/Google

Let's do a study and compare Rich and Textual, which is based on Rich.

Here's a Textual class: https://textual.textualize.io/reference/events/#textual.events.MouseCapture. I need to find what is MessageTarget, so after some futile ctrl-f'ing I copy-paste it into search field. Suggestions show barely related results, like a code listing and another unit that references MessageTarget. Hitting Enter just drops me not onto a search results page but onto a barely related page that does not document MessageTarget at all.

Then I want to find out what Point is. I just go to Google for this. It shows me Geometry page, which seems related... Except it lands me at the top and do you know how many times "point" (and "pointer", "pointing", etc) are used on the page? Many times, which is why Google thinks it's probably the most related to Point. After a minute of ctrl-f'ing I find no docs for Point.

Note that at this point I don't even know whether either MessageTarget or Point is documented at all. If they aren't, then what a great use of my time!

Of course search engine doesn't have the slightest idea about what I need, it merely matches entered words. As you can see, search is the true grep for documentation that you are describing: dumb and barely useful by itself.

Here's a Rich class:…

> Using a general-purpose static site generator for Python docs feels just wrong

There's a spectrum on this; a lot of stuff in the async ecosystem uses mkdocs (FastAPI, etc.) for example. I'd also argue that Markdown is known by waaaaay more SWEs than Sphinx--I wrote a ton of Sphinx years ago and couldn't even tell you where to start today, but I'm fluent in Markdown because I use it everywhere. That says a lot.

Looking through the Textualize docs [0], they seem pretty good to me? It reminds me of most of the web UI toolkits I've used: components on the left, specific functions of the component you're viewing on the right. I think the advantages to Sphinx you're pointing out aren't super relevant to Textualize.

My day job's in Python, and I spend a lot of time reading through various Sphinx documentation. Sure it's possible to make a great Sphinx site, but most people just add bare minimum docstrings and leave you to figure out the rest. Like you say, people generate docs, and I don't think Sphinx has extra magic that "makes you" generate better ones.

On the contrary, I think something that does help you generate better ones is liking your doc tool. If you're not into Sphinx, you're not gonna be enthused about writing excellent docs in it. If you're into mkdocs, you'll be more motivated to do so. The best exercise is the exercise you'll do, etc. etc.

[0]: https://textual.textualize.io/reference/app/

Hey there. This project isn't posted publicly anywhere at the moment—it's a very idiosyncratic one-of-one sort of deal.

For one thing, while I know Python a little bit, I much prefer to write Lisp. But the Textual [0] library is for Python and nothing else seems to even compete in the same space. So my "outlook-explorer" ("oe" on my command line) is actually written in Hy [1], a Lisp-y syntax swap that emits Python AST objects. And there's a couple places where I just hard-coded my own info, like the email address I'm using it with in order to pull from the right inbox in Outlook, that would need some kind of user-facing and reasonably user-friendly config options before it'd be ready for general consumption.

Have you thought about making your own bespoke one-of-one thing? I got much further than I expected to in only a couple hours. It was already basically functional in three hours, I think, and I came to the table with no prior experience using Textual.

[0] https://textual.textualize.io/

[1] https://hylang.org/

Did a cursory dive through, check: https://textual.textualize.io/tutorial/ and https://github.com/Textualize/textual/blob/main/docs/examples/tutorial/stopwatch.py

...what have people had success with in golang-world? Anything reasonably equivalent someone could recommend? There's a fair amount of "stuff" for TUI's in golang, the thing that's very attractive about 'textualize' is it feels very "web-browser-y" and has a nice (scrollable!) table view.

`tview` seems interesting (eg: check `brew install dbui`), but feels a bit more like _you're_ doing all the imperative `if KeyPress.A: do_something()` instead of declarative, nesting navigation, etc. (perhaps that's the difference between an "application-centric/SPA" view of "control all the things!" vs. a document centric: "add components to a page and let them flow").

Any feedback on the items in this list? https://codeberg.org/tecras/awesome-go#advanced-console-uis

Shameless plug: https://github.com/candidtim/f2-commander

I've been working on "F2 Commander" on and off for a while now. At first, I wanted a TUI to view the contents of cloud storage buckets (GCS, S3, etc.), but it quickly evolved into an orthodox file manager. The funny thing is, the first version was in Common Lisp, but then I discovered Textual and was instantly sold on it - it's really fun to work with. The app scratches my itch, and although most of the time I myself prefer just using the regular command line, I open it up when I need to quickly navigate or move some files in a complex directory tree.

[1] https://textual.textualize.io/