Textual is a beautiful Terminal User Interface library in Python
textual.textualize.io
textual.textualize.io
1. Considering it has actual paid developers working on it for quite a while and VC funding, it still lacks a great many features that I took for granted in all the non-commercial TUI libraries, e.g. menus and dialog boxes.
2. The async nature of the library is unpleasant. Can never be sure when/where your code will run.
3. Lots of 'magic' Python variables and methods that you have to override, but there's no way to discover them in your IDE through the type system.
4. Using CSS for laying out a TUI app makes no sense (unless you are a web developer and have Stockholm syndrome from using it for web apps?)
5. It seems to leak memory.
Eventually re-wrote the app from scratch using a different library that gets far less hype and spends no time marketing itself. The result was much better in every way.
The only criticisms above that really apply to Python are the async nature, and that’s only because getting async right in Python frameworks and libraries is hard, it is possible though, Django being a great example.
I tried to use urwid too and gave up. Python needs a library as good as ftxui for C++
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 leaking memory. If there was a memory leak, I'd make it a priority to fix.
Ultimately though, I'm glad you built your TUI.
He literally said what he found unpleasant about async. Which is the most common thing async novices find unpleasant.
You recently renamed the widget "Checkbox" to "Switch" in a newer version. I easily did a rename in my single file app. But imagine that someone built an extremely complicated TUI app containing dozens of files, you can easily miss a rename, which won't be caught by any static checking tools and only result in runtime error.
I had fun building simple apps using Textual, but I probably won't use it to build any complicated TUI apps. I feel that IDE/static checking tools unfriendly magic may directly hurt Textual adoption because it doesn't work with automated tasks like refactoring, and that prevents people from using it in large projects.
Like, hell, their examples have some *HUGE* buttons, starting with a calculator app that is all buttons - who is going to click on those? The calculator-with-buttons barely makes sense for desktop GUI apps (it was helpful back in the 80s when everyone had a physical calculator on their desk to help see the metaphor of the "virtual desktop" and it is arguably helpful on touch screen devices today for obvious reasons, but on a machine with a keyboard it is superfluous), let alone TUIs.
If you want to see a TUI that actually looks good (though a bit too much on the fancy side, but it doesn't pretend to be something it isn't) check btop:
https://textual.textualize.io/
Their examples in the link you sent are OK, the doc examples look crappy, and that's whats in the linked post.
From what i see the screenshots in the site you linked at are from programs made by others instead of Textualize themselves, so perhaps they should take a note of how the people who actually use their library and make TUI applications style their programs and redesign theirs accordingly.
>3. Lots of 'magic' Python variables and methods that you have to override, but there's no way to discover them in your IDE through the type system ...
>5. It seems to leak memory.
Welcome to Python. =)
Python libs can and do use dunder method overrides, operator overloading, and so on. If it was common to rewrite the AST, or have other action-at-a-distance, I'd give this some credit, but those are still century old PL features, and well specified mechanisms, not something one can't reason about.
Python I find to be (and I'd say most find it to be, hence its popularity on fields like Physics and such, even by non-programmers by trade) one of the easiest languages to read programs in and understand their intent.
Which exacly library, say of the 100 most commonly used ones on Pypi to keep this focused, is particularly problematic?
Fun fact: CSS had, since CSS 2.0, the media type ‘tty’, for use in media queries targeting text browsers like links or lynx or such:
@media tty {
body {
max-width: 80ch;
}
}
But afaik ‘tty’ has never been implemented and as such never been used. In CSS Media Queries Level 4 all media types outside of ‘all’ and ‘screen’ have been deprecated.
And ‘print’. The deprecated and now-never-matching media types are: tty, tv, projection, handheld, braille, embossed, aural, speech.
Source: https://www.w3.org/TR/mediaqueries-4/#media-types
(Also observe the note: “it is expected that all of the media types will also be deprecated in time, as appropriate media features are defined which capture their important differences.” Although features are a technically superior approach, replacing print in this way is never going to be particularly practical or pragmatic. I’m not convinced they’ll ever get to that point, and am confident they will never take the same deprecation route for ‘print’ as they have for the rest, making them never-matching (and ‘all’ and ‘screen’ are certainly not going to get that treatment).)
Reminder that “Stockholm Syndrome” is not only universally invoked as a dismissive, thought-terminating cliché, it was also literally invented out of a whole cloth for just that purpose, as a pretext for dismissing legitimate criticism by a person with significant responsibility for the decision being criticized.
The Textual blog[2] is a great place to keep up with new features, along with interesting articles about problems encountered (and solved) during development.
Incidentally, Textual[3] is also the name of a very popular open-source[4] IRC client for macOS
[0] https://github.com/charmbracelet/bubbletea [1] https://github.com/charmbracelet/bubbles [2] https://textual.textualize.io/blog/ [3] https://www.codeux.com/textual/ [4] https://github.com/Codeux-Software/Textual
And for Rich: https://www.textualize.io/rich/gallery
I use terminal apps precisely because I want a lot of information density and responsiveness.
But perhaps the screenshots are not comprehensive enough to show what it can do.
Well on the latter two, I realized I had a huge uphill battle, as SSH apparently uses CRLF over LF, and I was finding myself having to rewrite half the library to accommodate that.*
And on the former, it occurred to me that I hate everything about Python's asyncio. I'm sure that'll anger some, but sorry, it's terrible, and it doesn't help that every major version deprecates something in favor of something new.
[*] Any advice here would be welcome. I can't find much literature on the subject.
Also - can you elaborate on how the CRLF vs LF broke your app? Give a code snippet as an example?
As for the CRLF/LF issue, I paired textual with AsyncSSH, and was successful in making an SSH service hosting the app. However, connecting resulted in a text soup that I initially assumed was the fault of AsyncSSH. After some time, I realized it was due to the line-endings being defaulted to LF by rich (a reasonable decision in any other scenario.)
On both points, I'd be happy to share some snippets, but I'm halfway around the world from my home computer currently. If this is more than just a passing interest, I'd be happy to follow up upon my return.
If you want to post an issue on the repo, I think we could resolve it.
And my Emacs is pretty stock with native comp.
I agree that terminals are fetishised a bit, and I personally find a mix of GUIs and terminals to be the most effective combination, but I think there’s something valuable in the interaction pattern.
In VSCode there are probably ~1000 actions I can perform, and maybe ~50 keyboard shortcuts that I use, but I can still access all those actions quickly and fairly efficiently. This shows the value of command line interfaces.
The original comment was suggesting that the value was outdated, but I think command palettes are a good counter-example.
How? Every single TUI app i have on my system has its own look and feel, down to even using different keys for the same or similar tasks. At best a few have vi-like hjkl keys for movement (but no number prefix) and some might use ? for showing the available keys or some sort of help, but there is pretty much zero consistency beyond that.
At least in comparison the overwhelming majority of GUI applications agree on things like what Ctrl+C/X/V, Backspace, Del, Arrow, etc will do and they tend to react the same when you press the left mouse button on something that vaguely resembles a push button or a check box (most also agree how scrollbars work, though not all of them).
You could, but it's not exactly a great comparison. Contrast with Apple's history of HIGs and similar for a company that puts effort into consistency. Where's the equivalent in the TUI?
GUI apps are ever more bloated and often aren't written for power users (many shortcuts etc). Sure they can have all those things, but they don't. Also, UI designers are really strong trend followers meaning their apps will waste a lot of screen real estate and are often white on light gray right now because that seems to be the current fashion.
Also running apps remotely with a simple and fast interface is often really a big plus.
I do agree with you that many gui apps are poorly built and bloated.
But one thing I love about terminal applications is how nice they work on remote sessions.
I agree. Writing, testing, and documenting anything other than a CLI is so much more work, imo.
Almost certainly. But for whatever reason, most GUIs created happen to be really bad at the things that most TUIs I've used happen to be really good at, namely searchability, reflowability (mostly used to increase text size and change font face for legibilit), and keyboard navigation.
GUIs that nail these things are delightful. They're highly accessible and extremely efficient to use. But it also seems to me like the full power afforded by GUI toolkits leads a lot of developers to pour a lot of time and effort into other things (which matter less, at least to me, personally) while totally neglecting those aspects of their apps.
Both of these assume *nix cli and not windows.
was not turbo pascal circa 1993 kind of ... easier to use than the text uis we have now?
Or rather beautiful in what sense? Source code, architecture, or what?