[HN Gopher] Textual is a beautiful Terminal User Interface libra...
       ___________________________________________________________________
        
       Textual is a beautiful Terminal User Interface library in Python
        
       Author : joss82
       Score  : 140 points
       Date   : 2023-03-12 17:43 UTC (5 hours ago)
        
 (HTM) web link (textual.textualize.io)
 (TXT) w3m dump (textual.textualize.io)
        
       | wkat4242 wrote:
       | Judging only by the screenshots it feels like this library is
       | embracing the same "modern" design as mobile apps. Huge buttons,
       | lots of whitespace everywhere.
       | 
       | 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.
        
       | BaculumMeumEst wrote:
       | i invite you change my view: there is absolutely no reason to
       | fetishize the terminal. it's a shitty interactive window with
       | needless constraints. anything you can do in a tui can be done
       | better in an actual graphical window.
        
         | wkat4242 wrote:
         | Agreed in principe but we live in the real world.
         | 
         | 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.
        
         | avgcorrection wrote:
         | Well, I don't know about _in general_ but I think this is the
         | case for Emacs except maybe for some remote session use-cases.
        
         | [deleted]
        
         | ducktective wrote:
         | one word: latency
        
           | BaculumMeumEst wrote:
           | that seems dependent on the gui and terminal in question. on
           | windows, a graphical emacs window has less perceptible
           | latency then a terminal window
        
             | ducktective wrote:
             | All non-electron terminals have better latency story than
             | cross platform GUIs. Surprised you mentioned Emacs here as
             | it is notoriously laggish in this department.
        
         | danpalmer wrote:
         | I'd suggest that the proliferation of software with many
         | possible interactions adding features that let you invoke
         | actions via a command-line like interface (see Ctrl+P command
         | palettes etc) prove that there is a place for these sorts of
         | interfaces. Using a mouse is inefficient, and there are only so
         | many hot keys one can assign and learn.
         | 
         | 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.
        
           | BaculumMeumEst wrote:
           | nothing is stopping gui programs from using keyboard
           | shortcuts though. vs code and emacs use them to great effect.
           | and there's no quirks with the alt key.
        
             | danpalmer wrote:
             | As I said though, there are only so many keys on a
             | keyboard, and only so many combinations one can learn,
             | which is why command palette style interfaces have become
             | so popular.
             | 
             | 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.
        
         | kataklasm wrote:
         | At least for me, apart from all the other obvious reasons to
         | use a TUI, a big part of it is the fact that it's so much
         | easier to get a coherent and consistent user interface with
         | TUIs compared to GUIs. Every GUI uses a different UI system and
         | as such will look incoherent with other apps. Just take GTK vs
         | Qt.The UI of my daily machine looks extremely coherent and most
         | of that is contributed to most of my programs being CLI or TUI.
        
           | badsectoracula wrote:
           | > consistent user interface with TUIs
           | 
           | 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).
        
         | sprash wrote:
         | The biggest problem with GUIs is that there is no reliable
         | standard that works everywhere. The VT100 standard is 45 years
         | old and will most likely work for the next 45 years. It is dead
         | simple to implement GUIs (just write to stdout) and all those
         | programs that use that protocol to render their GUI are
         | immediately portable to almost every platform on the planet and
         | work over the network via ssh without any additional need for
         | programming.
        
       | eddyg wrote:
       | Textual is fantastic, and with all the recent widget additions,
       | provides functionality on-par with Go's Bubble Tea[0] /
       | Bubbles[1] combo.
       | 
       | 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
        
       | billyjobob wrote:
       | I fell for the hype that Textual always gets on HN and actually
       | used it for a mid-sized commercial app a few months ago. I
       | figured it was a 'safe' choice, given all the developers here who
       | seem to like it, and it was the only TUI library I could find
       | with corporate backing. Here are my notes.
       | 
       | 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.
        
         | pmarreck wrote:
         | Seems like a lot of the negatives are tied to Python.
        
           | KyeRussell wrote:
           | Multiple points the user made seem to be this tool working
           | _against_ Python.
        
           | danpalmer wrote:
           | I'm not sure that's really accurate. I found the API rather
           | unpythonic, with lots of use of magic variables and things.
           | 
           | 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.
        
         | willm wrote:
         | 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 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.
        
         | badsectoracula wrote:
         | Related to #1 you mentioned, to me Textual looks just ugly -
         | like if someone thought it wasn't enough for desktop GUIs to be
         | infested with mobile phone UIs, it also has to be the terminal
         | apps too.
         | 
         | 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://github.com/aristocratos/btop
        
         | pge wrote:
         | what library did you end up using instead?
        
         | typon wrote:
         | Exact same experience I had. I would also add that the CSS
         | styling doesn't really work. And it's frustrating because I
         | would prefer if it didn't work all time, but it seems to only
         | not work some of the time and I can't figure out the algorithm
         | of when it doesn't work.
         | 
         | I tried to use urwid too and gave up. Python needs a library as
         | good as ftxui for C++
        
         | stratosgear wrote:
         | I understand you mean no disrespect to the Textual author, but
         | i would still like to know your comparable alternative...
        
         | Dooflegna wrote:
         | Okay, but what is the different library...?
        
         | drakythe wrote:
         | Would very much like to know about the alternatives, please.
        
       | z3c0 wrote:
       | I really like Textual. I'm very much the TUI type, and upon
       | discovering it, I decided it would be my go-to for interfaces
       | going forward, as - ideally - I'd be able to run the same apps on
       | my desktop as my home server as my cloud servers.
       | 
       | 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.
        
         | schemescape wrote:
         | Are the CRLFs related to Windows? I've never encountered them
         | anywhere else...
        
           | z3c0 wrote:
           | Same, but I only run Debian-flavored Linux, so that theory
           | was ruled out pretty quickly. It appears to be a default
           | behavior of pseudo-terminals leftover from the days of yore,
           | when CRLF/LF was still an open debate.
        
         | willm wrote:
         | I'm not sure I understand your line endings issue. But we've
         | had Textual working over SSH.
         | 
         | If you want to post an issue on the repo, I think we could
         | resolve it.
        
         | einpoklum wrote:
         | "half the library" - half of textual, you mean?
         | 
         | Also - can you elaborate on how the CRLF vs LF broke your app?
         | Give a code snippet as an example?
        
           | z3c0 wrote:
           | Should've been more clear - I've had to update significant
           | portions of Textual _and_ rich to enable propagating custom
           | line-endings from the top level, but most of the code I
           | touched was in rich.
           | 
           | 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.
        
       | guitarbill wrote:
       | It's very nice that Textual has a text input widgets. Seems like
       | many TUI libraries have widgets, but lack one to handle text
       | input. So you have to implement this yourself over and over,
       | often forgetting shortcuts people expect (e.g. ctrl+a/e).
        
         | schemescape wrote:
         | What is Ctrl+e?
        
           | avgcorrection wrote:
           | Emacs/GNU readline keybinding for jumping to the end of the
           | line.
        
           | drakythe wrote:
           | Jump to the end of the line. Ctrl+a jumps to the beginning.
           | 
           | Both of these assume *nix cli and not windows.
        
       | benrutter wrote:
       | I don't really know why this post is appearing now given textual
       | is already at version 2 and not a new thing, but I love love
       | looovve textual. Alongside rich (also from textualize) its one of
       | those rare libraries that I can't find a single thing I'd change
       | in it.
        
       | riceart wrote:
       | [flagged]
        
         | lifeisstillgood wrote:
         | The top comment is several paragraphs of reasoned comment about
         | the features the poster tried and found lacking in the library
         | 
         | If you have experience of the library, which I guess you do to
         | arrive at your conclusion please share it - what was crap about
         | the library. What context was your experience? What could be
         | improved (even maybe the top posters decision - you can't
         | improve it just try something else).
         | 
         | Try Harder. Please.
        
       | lazzlazzlazz wrote:
       | Textual keeps coming up -- a perennial favorite on Hacker News.
       | But I have yet to encounter high-quality TUI applications that
       | use it. Why is that? Maybe I've messed them and people can post
       | their favorites.
        
       | fnordpiglet wrote:
       | Wish it had rust bindings
        
         | ducktective wrote:
         | I mean, it should be the other way around
        
       ___________________________________________________________________
       (page generated 2023-03-12 23:00 UTC)