20 ms·

Things I've learned building a modern TUI framework

439 points by willm 4y ago

wiso 4y ago
You don't really need new TUI framework, when you can extend existing real GUI framework to just work in console https://github.com/jinek/Consolonia https://github.com/jinek/Consolonia
shrx 4y ago
One thing that many TUIs struggle to get right is handling of backspace in input prompts. I can't remember how many times I had to restart a lengthy setup script from the beginning just because I made a typo somewhere and pressing backspace to correct it broke everything. One such recent example was with using Certbot to set up a LetsEncrypt certificate.
xialvjun 4y ago
I think the most valuable point of TUI is to run programs remotely with low traffic.
BiteCode_dev 4y ago
I really like this trend of "making the terminal great again". Between rich/textual in python and lipgloss/bubble tea for golang, this turns cmd from "the default ugly stuff that is easy to produce" into "something fun and pretty". Also note that those projects have the (not anymore) secret goal to also produce a web app from the same code base automatically. I imagine native will follow, or wasm, or something. Nevertheless, having the terminal as the smallest denominator for UI makes a lot of sense for small utilities. You won't build the next Figma with it but a lot of scripts could benefit from that.
- pjmlp 4y ago
  I really don't, I started my coding life on 8 bit computers, went through all MS-DOS versions starting with MS-DOS 3.3, and on the UNIX side with Xenix, all the time wishing stuff like the Amiga, Atari ST and Acorn would be the standard way of computing. Turbo Vision was the best TUI framework, with a compiled language, in 1990, 32 years ago! I really don't get this terminal nostalagia.
  - athrun 4y ago
    I personally think it's because in many ways we're not building native, snappy, keyboard-driven desktop apps any longer. Everything is moving to the web or web-like. Most of the apps I use at work are web-based and mouse-heavy. The overall slowness and latency of the UI is killing me. TUI apps represent a weird niche. People building them are _usually_ into providing a UX that is fast, productive, offline-first and composable (ie: lends itself to automation). It's a breath of fresh air.
    - nimrody 4y ago
      I agree. It's easier to build TUI apps (and more portable usually) then fully native GUI applications. Another point for TUI apps is that they are usually keyboard focused unlike GUI and webapps which require using the mouse (and are therefore less efficient)
- shreyshnaccount 4y ago
  imagine cross platform apps that work just as well on phones, and built using this type of almost scripting like code. (check out pywebio too)
  - ludston 4y ago
    Like a Web browser?
    - coconuthacker42 4y ago
      yes, minus the Javascript.
- zokier 4y ago
  I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no gratuitous animations or flourishes, allowing no-hassle adaptation to any colortheme and font. Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web? Furthermore the CLI proponent in me is saddened seeing this being largely another step away from CLI tools, although strictly speaking its true that the technology doesn't really define the interaction model.
  - leejoramo 4y ago
    As someone who started out using pre-PC micro-computers (TRS-80, Apple ][, CP/M), I often would like to have access to a good suite of what we now call TUI programs. Having a common TUI would be a bonus, which briefly existed back in Borland’s heyday.
  - suction 4y ago
    I agree. I immediately associate this with "show-off computing", which would probably look good on brain-dead TV shows about l33t haXors or "Anonymous" documentaries..but what's the point of slowing down your terminal even if it's just by 0.000001 seconds per keystroke only to look at Emojis? Will get old very fast.
  - happymellon 4y ago
    Aren't these all just the next evolution of ncurses? That's not exactly new, and has been around long enough that I dont think these other project are moving the cli any further away.
  - agumonkey 4y ago
    Most tui these days are not that functional. Compared to some as400 days apps or some old repls. Maybe recent projects are too frivolous but it's cool to see energy flowing there. More appealing than the heavy web imo.
  - clemens3 4y ago
    Yes, and some are even intended only for the X terminal, not the real TTY. What is missing is a nice library for high level languages, as ncurses is famous and all that, but who, unless they are coding in C, can interface with it and even understand the documentation.
- mastry 4y ago
  Agreed. I cut my programming teeth on the Dr. Dobbs/Al Stevens "D-flat" series which was a text-based windowing system in C. Some of the most fun I've ever had programming. The hardest part was waiting for the next issue to be published!
  - ghaerr 4y ago
    Funnily enough, I just happened to have ported D-Flat to macOS and Linux in the last couple of weeks. Check it out (w/screenshots): https://github.com/ghaerr/dflat https://github.com/ghaerr/dflat. It uses a small TUI library that maps multi-byte ANSI/xterm arrow key and mouse wheel inputs into unicode private-use codes for internal processing by D-Flat. It also remaps all of the IBM PC code page 437 characters for unicode output, and converts the entire "PC-compatible" screen image including attributes into ANSI terminal output, thanks to some nice code from the Cosmopolitan Project.
    - mastry 4y ago
      That is great - I starred the repo. Are the original articles available somewhere?
      - ghaerr 4y ago
        Yes, they're available on the archived Dr Dobbs Journal DVD V6 (https://archive.org/details/DDJDVD6 https://archive.org/details/DDJDVD6), starting in the May 1991 section, or thereabouts.
  - pjmlp 4y ago
    He eventually ported them into Turbo Pascal as well, that is when I bumped into the series.
  - password4321 4y ago
    I've tried to find the most recent version of that library, even emailing the author, but he's long since moved on and I could only find bits and pieces. Maybe https://archive.org/details/dflat https://archive.org/details/dflat is best now?
- mr_tristan 4y ago
  The general workflow I'm finding useful is to generate a ton of simple logs, ingest all those logs into a SQLite database (that acts like a "data lake"), and then use the customized REPL to generate some charts (typically .png files), CSV, or ascii reports. I could see using a REPL to generate a TUI, e.g., "run a query and generate your own `top`". This seems like it could be a lot easier than trying to generate a PDF, interactive Excel, or complex HTML report (which usually means a bunch of javaScript). There's something about text interfaces that just fundamentally "flows" from most programming environments.
nickdothutton 4y ago
It’s this kind of project that makes me want to run a shellhost/service/“club”. So much interesting stuff happening in the terminal these days for high-productivity individuals who are sick of the way the web has gone.
simonw 4y ago
This is all great, but I particularly liked the tip here on using Python Fraction objects for screen positioning calculations where floating point errors could result in a whole extra character causing display bugs.
- drewzero1 4y ago
  I think I missed the point of that exercise, so I appreciate your brief summary. Thanks!
nisegami 4y ago
Textual seems to be the right fit for a project I just started, but I have some concerns about its maturity and longevity. I feel better about both after reading the post (and seeing the call for applicants at the end despite the economy). Maybe I should just jump in.
silon42 4y ago
The biggest problems with terminals are: - some terminals support escape sequences that can do bad stuff (like when you accidentaly 'cat' a binary file - keyboard support is severly limited, especially regarding the Esc key and the modifiers.
- ilc 4y ago
  People underestimate this. But you are very right. I'll give a small story from my distant past: I went to a college with Sun IPCs and IPXs. It turns out, if you make the terminal beep on one, it is the HIGHEST priority thing the machine can do as far as we could tell. So when someone sent someone else, 2 megs of ^Gs via some mechanism usable in the 1990's, and recipient is sitting in the middle of a cathedral computing center. The machine literally will beep, and beep, and you can't stop it. That is a lot of bleeping, beeping. They had to power the poor machine off. Since I've used visual bell on every terminal program I use. Since I've turned on Virtual Bell in every terminal emulator, and I don't trust much on a terminal. May a terminal emulator author read my cautionary tale. (Before you ask: No I was not the user involved.)
  - wrycoder 4y ago
    Back in the day, this was called feeping creatures.
Philip-J-Fry 4y ago
This is great, it feels like it's one of the better frameworks that is actually trying to improve the way we write terminal UIs. Seems like Textualize is coming at it from the right angle, abstract as much as you can away such that a widget is something self contained and your UIs are actually composable à la web frameworks like React or Vue. Declarative UIs are the future. Now... When will someone make a Go port...
oblio 4y ago
Now instead of supporting 3 browsers (Chrome, Firefox, Safari) you now have to support 5 different terminals. Though it's probably easier to fully support a different terminal. Interesting trade offs.
- MaxBarraclough 4y ago
  Every multi-platform UI toolkit must put in the work to support multiple platforms, by definition.
jacobtomlinson 4y ago
I'm so excited about textual! I started working on a TUI application over Christmas that used it but put it on the back burner until the css branch gets merged.
K0nserv 4y ago
I wrote[0] something similar to the first part of this post a while back for one of the AoC 2019 puzzles. However, it didn't strike me that you can represent each frame as a set and use the difference to figure out the resulting render commands, that's super neat. Something strange that I found was: If you redraw only two characters in the terminal, neither iTerm nor macOS's terminal would render the update. In my solution I always rendered some characters redundantly to get around this. EDIT: I went back and looked at this code again based on the insights from this blog post and figured out a few more issues I had and fixed them. 0: https://hugotunius.se/2019/12/29/efficient-terminal-drawing-in-rust.html https://hugotunius.se/2019/12/29/efficient-terminal-drawing-...
MaxBarraclough 4y ago
A neat FOSS project. Have to admit I was surprised to see you're hiring and already have 2 developers on staff besides the founder. Where does the money come from? Paid support? It would be good if the What we do page answered this.
- asicsp 4y ago
  From https://www.willmcgugan.com/blog/tech/post/textualize-is-hiring/ https://www.willmcgugan.com/blog/tech/post/textualize-is-hir... >At the end of last year I took a year off to work on my Open-source projects and develop an idea that I believe will allow the terminal to eat some of the browser’s lunch. Turns out this idea was compelling enough to attract some sweet sweet VC cash and I am now hiring a third Python developer to join the company.
  - teddyh 4y ago
    The question then becomes: What do the VCs think that the money will come from?
    - stjohnswarts 4y ago
      VCs are naturally risk takers, there is a lot of VC money out there seeking novel projects. Maybe if textual can land some companies like Dell/IBM/AMD/Oracle/AWS who want snappier textual frontends for sysadmins rather than slow/clunky web interfaces for sysadmins/app admins to do stuff like board management controllers and textual dashboards for app/status monitoring stuff. Lower bandwidth/more dependable than web interfaces over slow/spotty interconnections with something like mosh. Seems like an option. Projects like this that add color, etc add a 3rd dimension to a 2 dimensional text landscape and I think that counts for a lot.
      - zasdffaa 4y ago
        Make me happy and point me at some of these because I have something and can find no-one to even look at it, and I believe it has actual cash value.
lotw_dot_site 4y ago
One of my proudest moments during the development of "Linux on the Web" had to be the creation of a Terminal application (try it at https://lotw.site/shell https://lotw.site/shell) that can render its output with near-native efficiency. My initial attempt was based on placing character images, one-by-one, onto a canvas element, but it was horribly sluggish. Then I started playing around with a "Virtual Dom" (React-like) approach, wherein I convert the underlying data structure into an html string, and then set the innerHTML property of a div element, for every time the screen has to be redrawn. (Source code: https://github.com/linuxontheweb/LOTW/blob/main/root/code/apps/sys/Terminal.js https://github.com/linuxontheweb/LOTW/blob/main/root/code/ap..., the relevant code is the "render" function starting on line 569, and the innerHTML is set on line 940). I don't know how many years its been that I started working on the Terminal application, but it was only within the past week or so that I "bit the bullet" and figured out how to do finger pad/mouse wheel scrolling of the output buffer (See the 'main.onwheel' function in the source code for that little tidbit!). Since I required fine-grained control over the rendering process, I could not rely on the "naive" way of doing scrolling on the web (which is to simply let the browser take care of the entire process).
- navanchauhan 4y ago
  Didn't look through GitHub to see if someone else has already mentioned the issue but it just shows a blank black screen when opened in Safari > Unhandled Promise Rejection: ReferenceError: Can't find variable: webkitResolveLocalFileSystemURL
  - lotw_dot_site 4y ago
    Yeah, I don't personally mess with anything but Chrome, and I consider supporting browsers that are not Chromium-based to be a fork of the entire project. Per the Disclaimer in the Github README (https://github.com/linuxontheweb/LOTW/ https://github.com/linuxontheweb/LOTW/): --------------- LOTW is developed in the crouton environment, which involves ChromeOS in developer mode. All development and testing is currently done on a Chromebook, using an up-to-date Chrome browser. The system should basically work in any modern browser and host OS, but there are likely many tiny glitches that degrade the user experience in other browsers and/or operating systems. --------------- The crucial fact of LOTW is that it is based around the concept of a full-featured, sandboxed file system in your browser. Only Chromium-based browsers natively support that kind of thing via 'webkitRequestFileSystem'. That being said, there is a shim/polyfill that is supposed to load and take care of that (https://github.com/linuxontheweb/LOTW/blob/main/www/js/fs-shim.js https://github.com/linuxontheweb/LOTW/blob/main/www/js/fs-sh..., created by Eric Bidelman when he was at Google). Last I knew, Firefox seemed to work with it.
Illniyar 4y ago
Everyone seems to be very excited about this framework, and while it looks very impressive, I don't inderstand the impetus for it. Why do I need the terminal to become an interactive visual app? Why not use the tools that are designed for visual interactive applications- like GUIs ?
- brabel 4y ago
  I am on the same boat: just can't see why someone would want to turn the terminal into what is basically a GUI with just poorer graphis?! Am I completely missing something? Should I start thinking of replacing my desktop environment with a terminal emulator that does everything, including displaying images, videos, windows etc to gain some advantage I am unaware of?
  - cwalv 4y ago
    It's a least common denominator thing: there a places where you can easily run a terminal app but not a browser/electron, which are probably the next level up in the portability/fidelity tradeoff.
  - BiteCode_dev 4y ago
    - you don't need compiled dependencies - you may work mostly in the terminal and want to fire a quick tool: dev is a lot of that so it's great for this use case - it's cross platform - it works with no X so it works with ssh - it doesn't eat a lot of resources - it's fast to launch - you usually already have a cli entry point, so this is a natural next step. The quick script becomes really nice - it's very constrained, so devs have to focus on the most important things which makes the UI usually better than usual - it's a common denominator so you can generate web ui and native ui form that - TUI have naturally good keyboard workflow for free - it's just really cool
    - stjohnswarts 4y ago
      - very low bandwidth
- 4y ago
shrubble 4y ago
For full-on terminal nuttiness, see the demo video (and it is like a demoscene video) at https://notcurses.com https://notcurses.com . Someday I will figure out how to use that library...
- robocat 4y ago
  Semi-pornographic soundtrack to the demo makes it feel rather non-professional to me (“penitrate my face” is not what I want to hear at work).
  - shrubble 4y ago
    Apologies, I watched the video but didn't catch that.
    - robocat 4y ago
      Yeah, no dig at you. Just warning those that would find it offensive.
mark_l_watson 4y ago
Really good that he got funding for his open source project. I tried Textualize earlier this year and it was really nice: easy to use and the UIs look great. Apologies in advance for drifting off topic: as (primarily) a Common Lisp developer, it makes me sad to see great Python projects that will never be replicated in my world. Perhaps there are 10,000 times as many Python developers as CL, so it is understandable.
- openfuture 4y ago
  There's a nice TUI lib for cl that I am using for tala (my take on this "TUIs will eat the web" thing... datalisp.is).
  - mark_l_watson 4y ago
    thank you!! EDIT: do you mean cl-tui?
    - openfuture 4y ago
      croatoan is the one I am using
skavi 4y ago
Why don’t more languages offer a zero allocation way to view a HashMap K V as a HashSet K.
public_defender 4y ago
Has anything been built with textual yet? People here seem to be discussing it mostly at the conceptual level.
- andrewshadura 4y ago
  I'm considering porting git-crecord to it, but the lack of documentation isn't particularly motivating :)
- willm 4y ago
  We have a gallery of apps in https://www.textualize.io/textual/gallery https://www.textualize.io/textual/gallery I'm surprised how much has been done with it. The version in master has been stuck in limbo while we've been working on the CSS branch.
  - jpeeler 4y ago
    The delta between main and the css branch is huge. Is there a plan for getting it into a tagged release? (Three months ago you basically said the same thing[1] as far as what's being focused on.) I know that you said you wanted to move away from Gitter, but somebody else recently had the same question [2]. It sounds like at this point you're starting to expect people closer to the code to use the css branch? [3] [1] - https://news.ycombinator.com/item?id=31151315 https://news.ycombinator.com/item?id=31151315 [2] - https://gitter.im/textual-ui/community?at=62e799a2b16e8236e34b7dbb https://gitter.im/textual-ui/community?at=62e799a2b16e8236e3... [3] - https://community.textualize.io/t/api-stability-of-css-branch-and-sample-code-for-home-page-example/17/6 https://community.textualize.io/t/api-stability-of-css-branc...
sebastianconcpt 4y ago
OMG you using CSS for stying the TUI??! I love this! Please tell me you can have window widgets Like a modern Turbo Vision [1] where you can drag/drop them even one on top of the other? [1] http://tvision.sourceforge.net/#wtv http://tvision.sourceforge.net/#wtv
- willm 4y ago
  Yup, it's a subset of CSS of course. But you will be right at home if you know CSS. We support multiple layers, but we are explicitly not advocating windows that can be dragged around. It wouldn't be hard to build, but I feel TUIs should avoid the requirement to shuffle windows around like a desktop app.
  - sebastianconcpt 4y ago
    App design should be the prerogative of the product designers? Anyway, I really like what you're trying with Textualize. So close. Window views would be the last deal breaker to remove for the product I was thinking about. If eventually later gets implemented I'll definitively take a look/try to make a PoC!
  - mixmastamyk 4y ago
    Working notebook tabs should be fine in the short term. Don't think those were mainstream in the TV days, which was more the MDI era. Also, please make them look like actual tabs, which TUI and Web designers avoid like the plague for some reason. :-P
baobob 4y ago
Does Textualize have a good example application? I was impressed by the demos (moreso that the company is somehow funded!), but I couldn't find any actual real world application using it yet. Also reliance on the mouse in the demos made me feel a bit queasy. Anything involving overriding the default mouse semantics in a terminal window can go straight to hell
- willm 4y ago
  We have a [gallery](https://www.textualize.io/textual/gallery https://www.textualize.io/textual/gallery) of Textual apps, although largely using the older version on Textual/
deleted 4y ago
[deleted]
chrismorgan 4y ago
I’m a little disappointed to see no mention of the problems of colour. Perhaps Textual is just too firmly in the camp of overriding everything, so that these problems don’t appear (and it just feels extremely heavily out of place instead). As a user of a light, high-contrast terminal, I will state that most TUIs that I use are badly executed, featuring awful ugliness, complete inaccessibility, or both, due to incorrect assumptions about colour. Terminals just have the wrong primitives for colour. It’s irredeemably broken, needing complete replacement with an altogether different approach to colours, and I don’t even know quite what that approach would be, quite apart from the improbability of convincing people to implement it. There are default foreground and background colours, and they could be black and white, white and black, or just about anything, really. (People speak of 16- and 256-colour terminals, but they’re actually 18- and 258-colour.) You want to make your text stronger? Have fun. You’ll look at your terminal that does #ccc-on-#000 or similar, and try bold. One some terminals, this will also change the colour to #fff, but on others it won’t. You kind of want to, because bold-but-the-same-colour isn’t drawing the attention you want, so you figure you’ll set the colour to bright white. Well, now your text is completely invisible for may light terminal users. So you begrudgingly roll that back and decide to try yellow. Eh, it’s a bit dull, but not too bad. You’ll still get complaints from light terminal users, though, because although it does have the advantage of distinctiveness, it’s much lower contrast. Don’t even think of bright yellow, because that’s back to being almost invisible in most light terminals. Light terminal themes have to decide whether colours 8–15 mean “bright” (increase lightness and perhaps saturation) or “higher contrast” (where you decrease lightness). Having played the game, I can report that both choices will break some things, but that “bright” is probably the more reasonable of the two. But know that you can’t rely on any particular direction in the relationship between colours 0–7 and 8–15. You think you’ll get around all of this by setting background colours? Please don’t, this just guarantees that your app will feel completely out of place, and probably be unpleasant to use. You’re fed up with light terminal considerations? Well then, perhaps you’d like some blue in your dark terminal. Pity that there are still widely-used terminals out there where blue so dark that it’s almost invisible and extremely hard to read. And even bright blue is commonly mildly painful to read. So blue’s out for any length of text. My advice ends up: by default, you should not set any background colours, and for foregrounds you can use the default colour and colours 1 (red), 2 (green), 5 (purple) and 6 (teal), and I will graciously permit you to use colours 3 (yellow) and 4 (blue) for no more than one word at a time (e.g. “warning:” in yellow). Seriously. Until the user opts into anything else, treat the entire thing as a five-and-a-bit-colour terminal, because you’ll cause misery if you go any further. Never use colours 0, 7, 8 or 15 by default without determining what they and the default colours are, because they may be high contrast or zero contrast. You can also use bold, which may give brighter colours, whatever that means, but shouldn’t use colours 7–15 directly. In many terminals it is possible to determine what the default background and foreground colours and other colours are, and if you have a really good reason why you want to use a bunch more colours you can try reading them and at least doing something simple like switching between a light and dark theme, but I recommend against that, because setting backgrounds is still just generally… non-native is probably a decent way of putting it. Stay colour-neutral by default, fit in rather than standing out. This is hardly the only place terminals are using a fundamentally bad model. The article does talk about the problems of column widths, seen especially in emoji. We seriously need to burn the current scheme of terminals down and build something sound in its place. Of course, this is extraordinarily unlikely to happen, and only stands any chance whatsoever if compatibility can be maintained in some way.
forrestthewoods 4y ago
I’m sad that Python is so slow it needs an LRU cache for trivial math operations like computing the overlap between a pair of 2D rects.
- jart 4y ago
  In a world where computers usually go "fast enough" we can always count on Python to create opportunities to learn computer science.
jorgenbuilder 4y ago
I have to say that my immediate reaction is “why the *#%# would one want to render a gui in a terminal”
- mixmastamyk 4y ago
  Uses 1/100 the resources of a modern GUI, maybe 1/1000 of an electron app. Works over ssh.
  - pjmlp 4y ago
    Probably applies to X Windows as well, IBM Terminals had no issues running on 1994 hardware.
  - badsectoracula 4y ago
    Not necessarily. I did a quick conversion of the Calculator Textual example to Lazarus' LCL and if anything Textual seems to be using more memory[0] (i did use the PSS as a comparison - ideally i'd boot into a VM running a minimal Linux distro to avoid any interference by background stuff like systemd, etc and record the free memory before and running each one, but i don't want to spend that much time on it and PSS is a decent approximation for how much memory a process that shares memory with other processes would need). Note that i only converted the UI, i didn't implement the calculator logic but that shouldn't make any practical difference. [0] https://i.imgur.com/MkfN4pO.png https://i.imgur.com/MkfN4pO.png
    - mixmastamyk 4y ago
      Lazurus is old school, pity it isn’t used more. The Python lib is new, maybe needs optimization? But in the big picture holds. Wasn’t expecting folks to counter with Xlib or Win32.
      - badsectoracula 4y ago
        Lazarus (LCL actually) is a very big framework that sits on top of a toolkit (Gtk), it is already way far removed from Xlib or Win32 (and is certainly heavier than what it could be :-P). I'm not sure what you mean with "oldschool", if anything working with something like Qt or Gtk directly where you either specify the UI by manually creating widgets/objects or by using a separate UI editing program (that often only has a fraction of Lazarus' features) that only edits an approximation of the UI and stores it in what are essentially resource files (not very dissimilar in concept to the Win16 resource editing tool) is a bit more old-school in my mind (Lazarus on the other hand edits live objects that are serialized to/from disk, which incidentally is kinda similar to how -e.g.- a modern game engine like Unreal works... though Unreal's UI toolkit is worse than any of Qt/Gtk/etc combined :-/). The Python lib most likely needs more optimization, but my point was that a TUI program can still be more heavyweight than a GUI one (the original question about why rendering a GUI in a terminal after all). I'd agree if you only referenced Electron, but you also referenced other GUIs :-P.
fadjfadjiiitlz 4y ago
* Fortunately the Unicode database contains a mapping of which characters are single width and which are double. Rich (and Textual) will look up this database for every character it prints. Its not a cheap operation, but with a bit of engineering effort and caching (see lru_cache) it is fast enough. * A bitmap sounds suitably compact and fast. There are likely to be large intervals of double-only or single-only items so it may be even smaller. Regarding your hiring it would be nice to actually get a reply, and say why if you don't want a person.
kevin_thibedeau 4y ago
> Fortunately the Unicode database contains a mapping of which characters are single width and which are double. This doesn't work for all emoji. Some are categorized as ambiguous width and their rendered width is system dependent.
ketralnis 4y ago
I miss vbdos. This used to be so easy.
dragontamer 4y ago
> The first trick is "overwrite, don't clear". If you clear the "screen" and then add new content, you risk seeing a blank or partially blank frame for a brief moment. It's far better to overwrite the content in the terminal entirely so that there is no intermediate blank frame. > The second trick [...] > The third trick [...] This is pretty hilarious to consider when coming from Win32API. Its traditional to clears the window before showing anything on Win32. Clearing the window happens so fast that you shouldn't see a flicker, even as the mouse moves over your window (each pixel your mouse cursor moves, Win32API will clear the window to its background, redraw the window (erasing the old mouse pointer), and draw the mouse pointer in the new location. This "TUI needs to be overwritten, not cleared" idea seems quaint and slow. Win32API was drawRect(background color) for decades on ancient 386 machines and fast enough to deliver a good experience. Why is a 80 x 24 terminal window so much slower? > In Textual the layout process creates a "render map". Basically a mapping of the Widget on to it's location on the screen. In an earlier version, Textual would do a wasteful refresh of the entire screen if even a single widget changed position. I wanted to avoid that by comparing the before and after render map. Win32API creates and maintains the "invalidRect", the rectangle that needs to be re-rendered from scratch (ie: draw-calls called upon the hierarchy of "windows" from the background to foreground, in order , to make the overall window look unchanged). Not only from mouse-cursor movements, but also as other windows "move" ontop of your window, or Clippy's speech bubble disappears (if you remember that little UI from the 90s version of Microsoft Word). And again, this needed to be done every time the mouse moved one pixel, to erase the old mouse cursor (aka: redraw the entire window from scratch "over" the old mouse cursor, making it look like you've erased it) and redraw the mouse cursor on top of the fresh coat of paint. It was an incredibly common operation even in 20MHz 80386 land from the early `90s. There's just no way a modern terminal is that slow, unless there's a billion layers of vsync / refreshes going on. There's definitely something wrong going on IMO here. > Unicode art is good This is true. Heck, ASCII art / symbols are often good enough to do many, many things. There's something wrong with the terminal model at the fundamental level if you're a couple of magnitudes slower than the 1980s. I can't say I'm an expert on TUI (or guis for that matter), but... this whole blog post is kind of a horror story IMO.
- willm 4y ago
  Win32API was designed to render a GUI from day 1. The terminal protocol pre-dates Windows and wasn't designed with modern hardware in mind. It's not that it is slow per se.
idomi 4y ago
There are so much stuff you could do with it right?
kmike84 4y ago
The advice to use lru_cache is good. But there is an issue if lru_cache is used on methods, like in the example given in the article: 1. When lru_cache is used on a method, `self` is used as a part of cache key. That's good, because there is a single cache for all instances, and using self as a part of the key allows not to share data between instances (it'd be incorrect in most cases). 2. But: because `self` is a part of a key, a reference to `self` is stored in the cache. 3. If there is a reference to Python object, it can't be deallocated. So, an instance can't be deallocated until the cache is deallocated (or the entry is expired) - if a lru_cache'd method is called at least once. 4. Cache itself is never deallocated (well, at least until the class is destroyed, probably at Python shutdown). So, instances are kept in memory, unless the cache is over the size limit, and all entries for this instance are purged. I think there is a similar problem in the source code as well, e.g. https://github.com/Textualize/textual/blob/4d94df81e44b27fff52f0e38f4f109212e9e8c8a/src/textual/widgets/_directory_tree.py#L65 https://github.com/Textualize/textual/blob/4d94df81e44b27fff... - a DirectoryTree instance won't be deallocated if its render_tree_label method is called, at least until new cache records push out all the references to this particular instance. It may be important or not, depending on a situation, but it's good to be aware of this caveat. lru_cache is not a good fit for methods unfortunately.
- nerdponx 4y ago
  This is the kind of thing that makes perfect sense but is not at all obvious to most people using Python, and IMO should be a caveat in the official manual. Great explanation.
- ttymck 4y ago
  Does @staticmethod run into this same issue?
  - kmike84 4y ago
    No.
wolpoli 4y ago
I feel like these TUI projects are popping up as a rejection to the modern mobile first GUI. They are keyboard driven, have no pictures, have clear borders between sections of the app, and are truly focus on the content.
- nilespotter 4y ago
  No pictures, you say? Check out timg [1] to display videos and images in select terminals, or ranger, a file manager with image [2] & video [3] previews! [1] https://github.com/hzeller/timg/ https://github.com/hzeller/timg/ [2] https://github.com/ranger/ranger/wiki/Image-Previews https://github.com/ranger/ranger/wiki/Image-Previews [3] https://github.com/ranger/ranger/wiki/Video-Previews https://github.com/ranger/ranger/wiki/Video-Previews
- badsectoracula 4y ago
  The linked video looks like it follows mobile/web styling though, it feels like if you could run a modern mobile-first web site through elinks. Sure there aren't pictures (which is really the least of modern GUI issues) but everything looks "flat" with big sizes (e.g. scrollbars) and aside from background color there isn't any other distinction between elements. Compare this with, e.g., the Debian textmode installer (which i guess is based on the Newt TUI library) or the console version of Yast in openSUSE (which is based on libyui, itself using ncurses for the console backend). In those the elements are very clear (though Newt's buttons are a bit too big IMO), scrollbars are thin (perhaps too think for libyui) and everything has a clear border. Also no scrolling areas inside scrolling areas, which is always annoying. [0] https://news.softpedia.com/images/reviews/large/debianinstallation-large_007.png https://news.softpedia.com/images/reviews/large/debianinstal... [1] https://documentation.suse.com/sles/15-GA/html/SLES-all/images/yast2_ncurses_inst.png https://documentation.suse.com/sles/15-GA/html/SLES-all/imag...
dahfizz 4y ago
This is really cool! I was impressed by the demo. I would be sad to see this replace a more "traditional" cli/tui, but for highly complex command line applications like qemu this is really awesome!
mixmastamyk 4y ago
I like this, seems to be the answer to the promise of Urwid. Unfortunately the main developer of which left for a long time once it hit 1.0. It was enough to build a widget toolkit, but didn't get proper widgets implemented for long enough that I lost track. I wanted to build an CUA terminal editor with one of these for decades but micro is recently good enough. So am cheering on in spirit.
rochak 4y ago
I love TUI and CLI based tools that keep me in my terminal as I have started to dread web applications more and more with every passing day. For obvious reasons, these tools have a better and more consistent UX since they need to rely on keyboard a lot more and are catered to more tech minded people. Not to mention the fact that they help avoid getting distracted by the endless ocean that is the internet.
- thrown_22 4y ago
  This framework, and every other one like it, is removing everything you liked about the terminal and turning it into a slightly less cluttered web browser. Give it 10 years and it won't be less cluttered.
  - rochak 4y ago
    Well, good part is that I get to choose what I like and stick to those. I’m a big fan of Vim, Tmux, Vifm, Lazygit and look forward to what the future holds.
    - thrown_22 4y ago
      Until there's a coup, Moolenaar gets kicked out, a new bunch of people you've never heard of take over and run the project into the ground all while telling you you're doing it wrong. It happened to GTK, it will happen to you too.
tambourine_man 4y ago
Every time I see that scrolling demo my jaw drops. It never gets old. I've been using terminals for too long and the expectation of what should be possible is engrained deep. I want tmux to scroll and have hover states like that.
lilyball 4y ago
A key weakness of TUIs is the complete lack of accessibility. Everything is characters arranged for the eye to see, there's nothing at all for screen readers to use to extract semantic meaning.
- trebbble 4y ago
  I'm having trouble imagining how to solve this in the terminal itself—there a way to pass information to a screen-reader via some kind of side channel?
  - lilyball 4y ago
    Terminals are GUI apps. In theory there could be a protocol for telling the terminal everything it needs to know for accessibility, and then convincing all terminal emulators to actually implement this, but it sounds like a nightmare.
- stjohnswarts 4y ago
  Very true, I don't even know how it would be possible without OCR that's "smart" about regions or a universal library in use that presented a way for software to see "what's going on" (pretty much a DOM equivalent)
- xavdid 4y ago
  Presumably command output with no chrome at all (only text content) would work well in a screen reader. So, I'd think the most accessible thing (today) would be to have an escape hatch to strip the output to its bones. Someone else who knows more about accessibility may know more though!
cbm-vic-20 4y ago
Most of these modern TUIs don't work on real "glass" terminals. Sure, nobody uses them anymore. I asked one of the Charm developer relations people if their stuff worked on old-school terminals like the VT-420, but they'd never even heard of that, didn't know what it was. Of course, the VT-420 came out before they were born, but still...
- azinman2 4y ago
  Do you use a VT-420?
  - cbm-vic-20 4y ago
    I do! I usually have it connected to a Raspberry Pi and use it mostly for IRC, but also for retroprogramming projects.
  - indymike 4y ago
    I used to keep a Zenith Z-29 terminal around that I bought (in new in the box condition) at a college surplus sale. I loved the keyboard on it and say what you will, green monochrome was really easy on the eyes (especially versus pre-super vga color screens). I used the Z-29 with a debugging card (it had a serial port) and when Linux took off, I used it as a terminal. It did well until the mid 00's when everything started expecting unicode support.
viksit 4y ago
Interesting other library - React for the terminal. Allows you to build the UIs using familiar web techniques and even has react dev tools! https://github.com/vadimdemedes/ink https://github.com/vadimdemedes/ink
sowbug 4y ago
> Unicode art is good This use case is crying out for a Textual-based ASCII art editor.
asciimov 4y ago
Seeing the amount of y’all excited about the guification of the terminal makes me concerned. I get it, this is a reaction to the appifying the browser. Please don’t turn to the terminal as a panacea for browsers. I don’t want my cli apps to suddenly be colorful or worse have css. Go back to making native apps, they are significantly better at doing interfaces than a terminal emulator. /rant
- nixpulvis 4y ago
  Exactly. Don't forget the UNIX philosophy. We build composable programs for the good of other use cases.
- robomartin 4y ago
  Having just delivered a “quick” console-based app to run a hardware product we manufacture, I fully sympathize with your comment. I have been coding for about 40 years. I can’t even remember the number of advanced text-based applications I wrote way back when that was it. Full menus, trees, scrolling regions, pop-up dialogs, color, even mouse input when it became available. As they say, ‘been there, done that. I decided to go console-based this time to roll out something quickly. We are working on a full GUI app, which was not going to be ready on time. Well, I put “quick” in quotes above because it was far from quick. I guess I forgot how much work these things can be. And, to your point, how much you end-up reinventing a perfectly good wheel. In retrospect, I should have told our customer to wait another week and deliver a far more capable product using wxPython. Lesson learned. Again.
hipjiveguy 4y ago
Terminals aren't "interactive prompts". They're requests. All requests need to be iterated on, in real time. So no one asks the perfect question immediately - it takes attempts, where the answer is no, or failure. So how fast we can interpret what the answer a terminal gives us is important. And a picture, or immediate visual interpretation, is worth more than a thousand words.

439 points by willm 4y ago

wiso 4y ago

You don't really need new TUI framework, when you can extend existing real GUI framework to just work in console https://github.com/jinek/Consolonia https://github.com/jinek/Consolonia

shrx 4y ago

One thing that many TUIs struggle to get right is handling of backspace in input prompts. I can't remember how many times I had to restart a lengthy setup script from the beginning just because I made a typo somewhere and pressing backspace to correct it broke everything. One such recent example was with using Certbot to set up a LetsEncrypt certificate.

xialvjun 4y ago

I think the most valuable point of TUI is to run programs remotely with low traffic.

BiteCode_dev 4y ago

I really like this trend of "making the terminal great again". Between rich/textual in python and lipgloss/bubble tea for golang, this turns cmd from "the default ugly stuff that is easy to produce" into "something fun and pretty". Also note that those projects have the (not anymore) secret goal to also produce a web app from the same code base automatically. I imagine native will follow, or wasm, or something. Nevertheless, having the terminal as the smallest denominator for UI makes a lot of sense for small utilities. You won't build the next Figma with it but a lot of scripts could benefit from that.

pjmlp 4y ago
I really don't, I started my coding life on 8 bit computers, went through all MS-DOS versions starting with MS-DOS 3.3, and on the UNIX side with Xenix, all the time wishing stuff like the Amiga, Atari ST and Acorn would be the standard way of computing. Turbo Vision was the best TUI framework, with a compiled language, in 1990, 32 years ago! I really don't get this terminal nostalagia.
- athrun 4y ago
  I personally think it's because in many ways we're not building native, snappy, keyboard-driven desktop apps any longer. Everything is moving to the web or web-like. Most of the apps I use at work are web-based and mouse-heavy. The overall slowness and latency of the UI is killing me. TUI apps represent a weird niche. People building them are _usually_ into providing a UX that is fast, productive, offline-first and composable (ie: lends itself to automation). It's a breath of fresh air.
  - nimrody 4y ago
    I agree. It's easier to build TUI apps (and more portable usually) then fully native GUI applications. Another point for TUI apps is that they are usually keyboard focused unlike GUI and webapps which require using the mouse (and are therefore less efficient)
shreyshnaccount 4y ago
imagine cross platform apps that work just as well on phones, and built using this type of almost scripting like code. (check out pywebio too)
- ludston 4y ago
  Like a Web browser?
  - coconuthacker42 4y ago
    yes, minus the Javascript.
zokier 4y ago
I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no gratuitous animations or flourishes, allowing no-hassle adaptation to any colortheme and font. Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web? Furthermore the CLI proponent in me is saddened seeing this being largely another step away from CLI tools, although strictly speaking its true that the technology doesn't really define the interaction model.
- leejoramo 4y ago
  As someone who started out using pre-PC micro-computers (TRS-80, Apple ][, CP/M), I often would like to have access to a good suite of what we now call TUI programs. Having a common TUI would be a bonus, which briefly existed back in Borland’s heyday.
- suction 4y ago
  I agree. I immediately associate this with "show-off computing", which would probably look good on brain-dead TV shows about l33t haXors or "Anonymous" documentaries..but what's the point of slowing down your terminal even if it's just by 0.000001 seconds per keystroke only to look at Emojis? Will get old very fast.
- happymellon 4y ago
  Aren't these all just the next evolution of ncurses? That's not exactly new, and has been around long enough that I dont think these other project are moving the cli any further away.
- agumonkey 4y ago
  Most tui these days are not that functional. Compared to some as400 days apps or some old repls. Maybe recent projects are too frivolous but it's cool to see energy flowing there. More appealing than the heavy web imo.
- clemens3 4y ago
  Yes, and some are even intended only for the X terminal, not the real TTY. What is missing is a nice library for high level languages, as ncurses is famous and all that, but who, unless they are coding in C, can interface with it and even understand the documentation.
mastry 4y ago
Agreed. I cut my programming teeth on the Dr. Dobbs/Al Stevens "D-flat" series which was a text-based windowing system in C. Some of the most fun I've ever had programming. The hardest part was waiting for the next issue to be published!
- ghaerr 4y ago
  Funnily enough, I just happened to have ported D-Flat to macOS and Linux in the last couple of weeks. Check it out (w/screenshots): https://github.com/ghaerr/dflat https://github.com/ghaerr/dflat. It uses a small TUI library that maps multi-byte ANSI/xterm arrow key and mouse wheel inputs into unicode private-use codes for internal processing by D-Flat. It also remaps all of the IBM PC code page 437 characters for unicode output, and converts the entire "PC-compatible" screen image including attributes into ANSI terminal output, thanks to some nice code from the Cosmopolitan Project.
  - mastry 4y ago
    That is great - I starred the repo. Are the original articles available somewhere?
    - ghaerr 4y ago
      Yes, they're available on the archived Dr Dobbs Journal DVD V6 (https://archive.org/details/DDJDVD6 https://archive.org/details/DDJDVD6), starting in the May 1991 section, or thereabouts.
- pjmlp 4y ago
  He eventually ported them into Turbo Pascal as well, that is when I bumped into the series.
- password4321 4y ago
  I've tried to find the most recent version of that library, even emailing the author, but he's long since moved on and I could only find bits and pieces. Maybe https://archive.org/details/dflat https://archive.org/details/dflat is best now?
mr_tristan 4y ago
The general workflow I'm finding useful is to generate a ton of simple logs, ingest all those logs into a SQLite database (that acts like a "data lake"), and then use the customized REPL to generate some charts (typically .png files), CSV, or ascii reports. I could see using a REPL to generate a TUI, e.g., "run a query and generate your own `top`". This seems like it could be a lot easier than trying to generate a PDF, interactive Excel, or complex HTML report (which usually means a bunch of javaScript). There's something about text interfaces that just fundamentally "flows" from most programming environments.

nickdothutton 4y ago

It’s this kind of project that makes me want to run a shellhost/service/“club”. So much interesting stuff happening in the terminal these days for high-productivity individuals who are sick of the way the web has gone.

simonw 4y ago

This is all great, but I particularly liked the tip here on using Python Fraction objects for screen positioning calculations where floating point errors could result in a whole extra character causing display bugs.

drewzero1 4y ago
I think I missed the point of that exercise, so I appreciate your brief summary. Thanks!

nisegami 4y ago

Textual seems to be the right fit for a project I just started, but I have some concerns about its maturity and longevity. I feel better about both after reading the post (and seeing the call for applicants at the end despite the economy). Maybe I should just jump in.

silon42 4y ago

The biggest problems with terminals are: - some terminals support escape sequences that can do bad stuff (like when you accidentaly 'cat' a binary file - keyboard support is severly limited, especially regarding the Esc key and the modifiers.

ilc 4y ago
People underestimate this. But you are very right. I'll give a small story from my distant past: I went to a college with Sun IPCs and IPXs. It turns out, if you make the terminal beep on one, it is the HIGHEST priority thing the machine can do as far as we could tell. So when someone sent someone else, 2 megs of ^Gs via some mechanism usable in the 1990's, and recipient is sitting in the middle of a cathedral computing center. The machine literally will beep, and beep, and you can't stop it. That is a lot of bleeping, beeping. They had to power the poor machine off. Since I've used visual bell on every terminal program I use. Since I've turned on Virtual Bell in every terminal emulator, and I don't trust much on a terminal. May a terminal emulator author read my cautionary tale. (Before you ask: No I was not the user involved.)
- wrycoder 4y ago
  Back in the day, this was called feeping creatures.

Philip-J-Fry 4y ago

This is great, it feels like it's one of the better frameworks that is actually trying to improve the way we write terminal UIs. Seems like Textualize is coming at it from the right angle, abstract as much as you can away such that a widget is something self contained and your UIs are actually composable à la web frameworks like React or Vue. Declarative UIs are the future. Now... When will someone make a Go port...

oblio 4y ago

Now instead of supporting 3 browsers (Chrome, Firefox, Safari) you now have to support 5 different terminals. Though it's probably easier to fully support a different terminal. Interesting trade offs.

MaxBarraclough 4y ago
Every multi-platform UI toolkit must put in the work to support multiple platforms, by definition.

jacobtomlinson 4y ago

I'm so excited about textual! I started working on a TUI application over Christmas that used it but put it on the back burner until the css branch gets merged.

K0nserv 4y ago

I wrote[0] something similar to the first part of this post a while back for one of the AoC 2019 puzzles. However, it didn't strike me that you can represent each frame as a set and use the difference to figure out the resulting render commands, that's super neat. Something strange that I found was: If you redraw only two characters in the terminal, neither iTerm nor macOS's terminal would render the update. In my solution I always rendered some characters redundantly to get around this. EDIT: I went back and looked at this code again based on the insights from this blog post and figured out a few more issues I had and fixed them. 0: https://hugotunius.se/2019/12/29/efficient-terminal-drawing-in-rust.html https://hugotunius.se/2019/12/29/efficient-terminal-drawing-...

MaxBarraclough 4y ago

A neat FOSS project. Have to admit I was surprised to see you're hiring and already have 2 developers on staff besides the founder. Where does the money come from? Paid support? It would be good if the What we do page answered this.

asicsp 4y ago
From https://www.willmcgugan.com/blog/tech/post/textualize-is-hiring/ https://www.willmcgugan.com/blog/tech/post/textualize-is-hir... >At the end of last year I took a year off to work on my Open-source projects and develop an idea that I believe will allow the terminal to eat some of the browser’s lunch. Turns out this idea was compelling enough to attract some sweet sweet VC cash and I am now hiring a third Python developer to join the company.
- teddyh 4y ago
  The question then becomes: What do the VCs think that the money will come from?
  - stjohnswarts 4y ago
    VCs are naturally risk takers, there is a lot of VC money out there seeking novel projects. Maybe if textual can land some companies like Dell/IBM/AMD/Oracle/AWS who want snappier textual frontends for sysadmins rather than slow/clunky web interfaces for sysadmins/app admins to do stuff like board management controllers and textual dashboards for app/status monitoring stuff. Lower bandwidth/more dependable than web interfaces over slow/spotty interconnections with something like mosh. Seems like an option. Projects like this that add color, etc add a 3rd dimension to a 2 dimensional text landscape and I think that counts for a lot.
    - zasdffaa 4y ago
      Make me happy and point me at some of these because I have something and can find no-one to even look at it, and I believe it has actual cash value.

lotw_dot_site 4y ago

One of my proudest moments during the development of "Linux on the Web" had to be the creation of a Terminal application (try it at https://lotw.site/shell https://lotw.site/shell) that can render its output with near-native efficiency. My initial attempt was based on placing character images, one-by-one, onto a canvas element, but it was horribly sluggish. Then I started playing around with a "Virtual Dom" (React-like) approach, wherein I convert the underlying data structure into an html string, and then set the innerHTML property of a div element, for every time the screen has to be redrawn. (Source code: https://github.com/linuxontheweb/LOTW/blob/main/root/code/apps/sys/Terminal.js https://github.com/linuxontheweb/LOTW/blob/main/root/code/ap..., the relevant code is the "render" function starting on line 569, and the innerHTML is set on line 940). I don't know how many years its been that I started working on the Terminal application, but it was only within the past week or so that I "bit the bullet" and figured out how to do finger pad/mouse wheel scrolling of the output buffer (See the 'main.onwheel' function in the source code for that little tidbit!). Since I required fine-grained control over the rendering process, I could not rely on the "naive" way of doing scrolling on the web (which is to simply let the browser take care of the entire process).

navanchauhan 4y ago
Didn't look through GitHub to see if someone else has already mentioned the issue but it just shows a blank black screen when opened in Safari > Unhandled Promise Rejection: ReferenceError: Can't find variable: webkitResolveLocalFileSystemURL
- lotw_dot_site 4y ago
  Yeah, I don't personally mess with anything but Chrome, and I consider supporting browsers that are not Chromium-based to be a fork of the entire project. Per the Disclaimer in the Github README (https://github.com/linuxontheweb/LOTW/ https://github.com/linuxontheweb/LOTW/): --------------- LOTW is developed in the crouton environment, which involves ChromeOS in developer mode. All development and testing is currently done on a Chromebook, using an up-to-date Chrome browser. The system should basically work in any modern browser and host OS, but there are likely many tiny glitches that degrade the user experience in other browsers and/or operating systems. --------------- The crucial fact of LOTW is that it is based around the concept of a full-featured, sandboxed file system in your browser. Only Chromium-based browsers natively support that kind of thing via 'webkitRequestFileSystem'. That being said, there is a shim/polyfill that is supposed to load and take care of that (https://github.com/linuxontheweb/LOTW/blob/main/www/js/fs-shim.js https://github.com/linuxontheweb/LOTW/blob/main/www/js/fs-sh..., created by Eric Bidelman when he was at Google). Last I knew, Firefox seemed to work with it.

Illniyar 4y ago

Everyone seems to be very excited about this framework, and while it looks very impressive, I don't inderstand the impetus for it. Why do I need the terminal to become an interactive visual app? Why not use the tools that are designed for visual interactive applications- like GUIs ?

brabel 4y ago
I am on the same boat: just can't see why someone would want to turn the terminal into what is basically a GUI with just poorer graphis?! Am I completely missing something? Should I start thinking of replacing my desktop environment with a terminal emulator that does everything, including displaying images, videos, windows etc to gain some advantage I am unaware of?
- cwalv 4y ago
  It's a least common denominator thing: there a places where you can easily run a terminal app but not a browser/electron, which are probably the next level up in the portability/fidelity tradeoff.
- BiteCode_dev 4y ago
  - you don't need compiled dependencies - you may work mostly in the terminal and want to fire a quick tool: dev is a lot of that so it's great for this use case - it's cross platform - it works with no X so it works with ssh - it doesn't eat a lot of resources - it's fast to launch - you usually already have a cli entry point, so this is a natural next step. The quick script becomes really nice - it's very constrained, so devs have to focus on the most important things which makes the UI usually better than usual - it's a common denominator so you can generate web ui and native ui form that - TUI have naturally good keyboard workflow for free - it's just really cool
  - stjohnswarts 4y ago
    - very low bandwidth
4y ago

shrubble 4y ago

For full-on terminal nuttiness, see the demo video (and it is like a demoscene video) at https://notcurses.com https://notcurses.com . Someday I will figure out how to use that library...

robocat 4y ago
Semi-pornographic soundtrack to the demo makes it feel rather non-professional to me (“penitrate my face” is not what I want to hear at work).
- shrubble 4y ago
  Apologies, I watched the video but didn't catch that.
  - robocat 4y ago
    Yeah, no dig at you. Just warning those that would find it offensive.

mark_l_watson 4y ago

Really good that he got funding for his open source project. I tried Textualize earlier this year and it was really nice: easy to use and the UIs look great. Apologies in advance for drifting off topic: as (primarily) a Common Lisp developer, it makes me sad to see great Python projects that will never be replicated in my world. Perhaps there are 10,000 times as many Python developers as CL, so it is understandable.

openfuture 4y ago
There's a nice TUI lib for cl that I am using for tala (my take on this "TUIs will eat the web" thing... datalisp.is).
- mark_l_watson 4y ago
  thank you!! EDIT: do you mean cl-tui?
  - openfuture 4y ago
    croatoan is the one I am using

skavi 4y ago

Why don’t more languages offer a zero allocation way to view a HashMap K V as a HashSet K.

public_defender 4y ago

Has anything been built with textual yet? People here seem to be discussing it mostly at the conceptual level.

andrewshadura 4y ago
I'm considering porting git-crecord to it, but the lack of documentation isn't particularly motivating :)
willm 4y ago
We have a gallery of apps in https://www.textualize.io/textual/gallery https://www.textualize.io/textual/gallery I'm surprised how much has been done with it. The version in master has been stuck in limbo while we've been working on the CSS branch.
- jpeeler 4y ago
  The delta between main and the css branch is huge. Is there a plan for getting it into a tagged release? (Three months ago you basically said the same thing[1] as far as what's being focused on.) I know that you said you wanted to move away from Gitter, but somebody else recently had the same question [2]. It sounds like at this point you're starting to expect people closer to the code to use the css branch? [3] [1] - https://news.ycombinator.com/item?id=31151315 https://news.ycombinator.com/item?id=31151315 [2] - https://gitter.im/textual-ui/community?at=62e799a2b16e8236e34b7dbb https://gitter.im/textual-ui/community?at=62e799a2b16e8236e3... [3] - https://community.textualize.io/t/api-stability-of-css-branch-and-sample-code-for-home-page-example/17/6 https://community.textualize.io/t/api-stability-of-css-branc...

sebastianconcpt 4y ago

OMG you using CSS for stying the TUI??! I love this! Please tell me you can have window widgets Like a modern Turbo Vision [1] where you can drag/drop them even one on top of the other? [1] http://tvision.sourceforge.net/#wtv http://tvision.sourceforge.net/#wtv

willm 4y ago
Yup, it's a subset of CSS of course. But you will be right at home if you know CSS. We support multiple layers, but we are explicitly not advocating windows that can be dragged around. It wouldn't be hard to build, but I feel TUIs should avoid the requirement to shuffle windows around like a desktop app.
- sebastianconcpt 4y ago
  App design should be the prerogative of the product designers? Anyway, I really like what you're trying with Textualize. So close. Window views would be the last deal breaker to remove for the product I was thinking about. If eventually later gets implemented I'll definitively take a look/try to make a PoC!
- mixmastamyk 4y ago
  Working notebook tabs should be fine in the short term. Don't think those were mainstream in the TV days, which was more the MDI era. Also, please make them look like actual tabs, which TUI and Web designers avoid like the plague for some reason. :-P

baobob 4y ago

Does Textualize have a good example application? I was impressed by the demos (moreso that the company is somehow funded!), but I couldn't find any actual real world application using it yet. Also reliance on the mouse in the demos made me feel a bit queasy. Anything involving overriding the default mouse semantics in a terminal window can go straight to hell

willm 4y ago
We have a [gallery](https://www.textualize.io/textual/gallery https://www.textualize.io/textual/gallery) of Textual apps, although largely using the older version on Textual/

deleted 4y ago

[deleted]

chrismorgan 4y ago

I’m a little disappointed to see no mention of the problems of colour. Perhaps Textual is just too firmly in the camp of overriding everything, so that these problems don’t appear (and it just feels extremely heavily out of place instead). As a user of a light, high-contrast terminal, I will state that most TUIs that I use are badly executed, featuring awful ugliness, complete inaccessibility, or both, due to incorrect assumptions about colour. Terminals just have the wrong primitives for colour. It’s irredeemably broken, needing complete replacement with an altogether different approach to colours, and I don’t even know quite what that approach would be, quite apart from the improbability of convincing people to implement it. There are default foreground and background colours, and they could be black and white, white and black, or just about anything, really. (People speak of 16- and 256-colour terminals, but they’re actually 18- and 258-colour.) You want to make your text stronger? Have fun. You’ll look at your terminal that does #ccc-on-#000 or similar, and try bold. One some terminals, this will also change the colour to #fff, but on others it won’t. You kind of want to, because bold-but-the-same-colour isn’t drawing the attention you want, so you figure you’ll set the colour to bright white. Well, now your text is completely invisible for may light terminal users. So you begrudgingly roll that back and decide to try yellow. Eh, it’s a bit dull, but not too bad. You’ll still get complaints from light terminal users, though, because although it does have the advantage of distinctiveness, it’s much lower contrast. Don’t even think of bright yellow, because that’s back to being almost invisible in most light terminals. Light terminal themes have to decide whether colours 8–15 mean “bright” (increase lightness and perhaps saturation) or “higher contrast” (where you decrease lightness). Having played the game, I can report that both choices will break some things, but that “bright” is probably the more reasonable of the two. But know that you can’t rely on any particular direction in the relationship between colours 0–7 and 8–15. You think you’ll get around all of this by setting background colours? Please don’t, this just guarantees that your app will feel completely out of place, and probably be unpleasant to use. You’re fed up with light terminal considerations? Well then, perhaps you’d like some blue in your dark terminal. Pity that there are still widely-used terminals out there where blue so dark that it’s almost invisible and extremely hard to read. And even bright blue is commonly mildly painful to read. So blue’s out for any length of text. My advice ends up: by default, you should not set any background colours, and for foregrounds you can use the default colour and colours 1 (red), 2 (green), 5 (purple) and 6 (teal), and I will graciously permit you to use colours 3 (yellow) and 4 (blue) for no more than one word at a time (e.g. “warning:” in yellow). Seriously. Until the user opts into anything else, treat the entire thing as a five-and-a-bit-colour terminal, because you’ll cause misery if you go any further. Never use colours 0, 7, 8 or 15 by default without determining what they and the default colours are, because they may be high contrast or zero contrast. You can also use bold, which may give brighter colours, whatever that means, but shouldn’t use colours 7–15 directly. In many terminals it is possible to determine what the default background and foreground colours and other colours are, and if you have a really good reason why you want to use a bunch more colours you can try reading them and at least doing something simple like switching between a light and dark theme, but I recommend against that, because setting backgrounds is still just generally… non-native is probably a decent way of putting it. Stay colour-neutral by default, fit in rather than standing out. This is hardly the only place terminals are using a fundamentally bad model. The article does talk about the problems of column widths, seen especially in emoji. We seriously need to burn the current scheme of terminals down and build something sound in its place. Of course, this is extraordinarily unlikely to happen, and only stands any chance whatsoever if compatibility can be maintained in some way.

forrestthewoods 4y ago

I’m sad that Python is so slow it needs an LRU cache for trivial math operations like computing the overlap between a pair of 2D rects.

jart 4y ago
In a world where computers usually go "fast enough" we can always count on Python to create opportunities to learn computer science.

jorgenbuilder 4y ago

I have to say that my immediate reaction is “why the *#%# would one want to render a gui in a terminal”

mixmastamyk 4y ago
Uses 1/100 the resources of a modern GUI, maybe 1/1000 of an electron app. Works over ssh.
- pjmlp 4y ago
  Probably applies to X Windows as well, IBM Terminals had no issues running on 1994 hardware.
- badsectoracula 4y ago
  Not necessarily. I did a quick conversion of the Calculator Textual example to Lazarus' LCL and if anything Textual seems to be using more memory[0] (i did use the PSS as a comparison - ideally i'd boot into a VM running a minimal Linux distro to avoid any interference by background stuff like systemd, etc and record the free memory before and running each one, but i don't want to spend that much time on it and PSS is a decent approximation for how much memory a process that shares memory with other processes would need). Note that i only converted the UI, i didn't implement the calculator logic but that shouldn't make any practical difference. [0] https://i.imgur.com/MkfN4pO.png https://i.imgur.com/MkfN4pO.png
  - mixmastamyk 4y ago
    Lazurus is old school, pity it isn’t used more. The Python lib is new, maybe needs optimization? But in the big picture holds. Wasn’t expecting folks to counter with Xlib or Win32.
    - badsectoracula 4y ago
      Lazarus (LCL actually) is a very big framework that sits on top of a toolkit (Gtk), it is already way far removed from Xlib or Win32 (and is certainly heavier than what it could be :-P). I'm not sure what you mean with "oldschool", if anything working with something like Qt or Gtk directly where you either specify the UI by manually creating widgets/objects or by using a separate UI editing program (that often only has a fraction of Lazarus' features) that only edits an approximation of the UI and stores it in what are essentially resource files (not very dissimilar in concept to the Win16 resource editing tool) is a bit more old-school in my mind (Lazarus on the other hand edits live objects that are serialized to/from disk, which incidentally is kinda similar to how -e.g.- a modern game engine like Unreal works... though Unreal's UI toolkit is worse than any of Qt/Gtk/etc combined :-/). The Python lib most likely needs more optimization, but my point was that a TUI program can still be more heavyweight than a GUI one (the original question about why rendering a GUI in a terminal after all). I'd agree if you only referenced Electron, but you also referenced other GUIs :-P.

fadjfadjiiitlz 4y ago

* Fortunately the Unicode database contains a mapping of which characters are single width and which are double. Rich (and Textual) will look up this database for every character it prints. Its not a cheap operation, but with a bit of engineering effort and caching (see lru_cache) it is fast enough. * A bitmap sounds suitably compact and fast. There are likely to be large intervals of double-only or single-only items so it may be even smaller. Regarding your hiring it would be nice to actually get a reply, and say why if you don't want a person.

kevin_thibedeau 4y ago

> Fortunately the Unicode database contains a mapping of which characters are single width and which are double. This doesn't work for all emoji. Some are categorized as ambiguous width and their rendered width is system dependent.

ketralnis 4y ago

I miss vbdos. This used to be so easy.

dragontamer 4y ago

> The first trick is "overwrite, don't clear". If you clear the "screen" and then add new content, you risk seeing a blank or partially blank frame for a brief moment. It's far better to overwrite the content in the terminal entirely so that there is no intermediate blank frame. > The second trick [...] > The third trick [...] This is pretty hilarious to consider when coming from Win32API. Its traditional to clears the window before showing anything on Win32. Clearing the window happens so fast that you shouldn't see a flicker, even as the mouse moves over your window (each pixel your mouse cursor moves, Win32API will clear the window to its background, redraw the window (erasing the old mouse pointer), and draw the mouse pointer in the new location. This "TUI needs to be overwritten, not cleared" idea seems quaint and slow. Win32API was drawRect(background color) for decades on ancient 386 machines and fast enough to deliver a good experience. Why is a 80 x 24 terminal window so much slower? > In Textual the layout process creates a "render map". Basically a mapping of the Widget on to it's location on the screen. In an earlier version, Textual would do a wasteful refresh of the entire screen if even a single widget changed position. I wanted to avoid that by comparing the before and after render map. Win32API creates and maintains the "invalidRect", the rectangle that needs to be re-rendered from scratch (ie: draw-calls called upon the hierarchy of "windows" from the background to foreground, in order , to make the overall window look unchanged). Not only from mouse-cursor movements, but also as other windows "move" ontop of your window, or Clippy's speech bubble disappears (if you remember that little UI from the 90s version of Microsoft Word). And again, this needed to be done every time the mouse moved one pixel, to erase the old mouse cursor (aka: redraw the entire window from scratch "over" the old mouse cursor, making it look like you've erased it) and redraw the mouse cursor on top of the fresh coat of paint. It was an incredibly common operation even in 20MHz 80386 land from the early `90s. There's just no way a modern terminal is that slow, unless there's a billion layers of vsync / refreshes going on. There's definitely something wrong going on IMO here. > Unicode art is good This is true. Heck, ASCII art / symbols are often good enough to do many, many things. There's something wrong with the terminal model at the fundamental level if you're a couple of magnitudes slower than the 1980s. I can't say I'm an expert on TUI (or guis for that matter), but... this whole blog post is kind of a horror story IMO.

willm 4y ago
Win32API was designed to render a GUI from day 1. The terminal protocol pre-dates Windows and wasn't designed with modern hardware in mind. It's not that it is slow per se.

idomi 4y ago

There are so much stuff you could do with it right?

kmike84 4y ago

The advice to use lru_cache is good. But there is an issue if lru_cache is used on methods, like in the example given in the article: 1. When lru_cache is used on a method, `self` is used as a part of cache key. That's good, because there is a single cache for all instances, and using self as a part of the key allows not to share data between instances (it'd be incorrect in most cases). 2. But: because `self` is a part of a key, a reference to `self` is stored in the cache. 3. If there is a reference to Python object, it can't be deallocated. So, an instance can't be deallocated until the cache is deallocated (or the entry is expired) - if a lru_cache'd method is called at least once. 4. Cache itself is never deallocated (well, at least until the class is destroyed, probably at Python shutdown). So, instances are kept in memory, unless the cache is over the size limit, and all entries for this instance are purged. I think there is a similar problem in the source code as well, e.g. https://github.com/Textualize/textual/blob/4d94df81e44b27fff52f0e38f4f109212e9e8c8a/src/textual/widgets/_directory_tree.py#L65 https://github.com/Textualize/textual/blob/4d94df81e44b27fff... - a DirectoryTree instance won't be deallocated if its render_tree_label method is called, at least until new cache records push out all the references to this particular instance. It may be important or not, depending on a situation, but it's good to be aware of this caveat. lru_cache is not a good fit for methods unfortunately.

nerdponx 4y ago
This is the kind of thing that makes perfect sense but is not at all obvious to most people using Python, and IMO should be a caveat in the official manual. Great explanation.
ttymck 4y ago
Does @staticmethod run into this same issue?
- kmike84 4y ago
  No.

wolpoli 4y ago

I feel like these TUI projects are popping up as a rejection to the modern mobile first GUI. They are keyboard driven, have no pictures, have clear borders between sections of the app, and are truly focus on the content.

nilespotter 4y ago
No pictures, you say? Check out timg [1] to display videos and images in select terminals, or ranger, a file manager with image [2] & video [3] previews! [1] https://github.com/hzeller/timg/ https://github.com/hzeller/timg/ [2] https://github.com/ranger/ranger/wiki/Image-Previews https://github.com/ranger/ranger/wiki/Image-Previews [3] https://github.com/ranger/ranger/wiki/Video-Previews https://github.com/ranger/ranger/wiki/Video-Previews
badsectoracula 4y ago
The linked video looks like it follows mobile/web styling though, it feels like if you could run a modern mobile-first web site through elinks. Sure there aren't pictures (which is really the least of modern GUI issues) but everything looks "flat" with big sizes (e.g. scrollbars) and aside from background color there isn't any other distinction between elements. Compare this with, e.g., the Debian textmode installer (which i guess is based on the Newt TUI library) or the console version of Yast in openSUSE (which is based on libyui, itself using ncurses for the console backend). In those the elements are very clear (though Newt's buttons are a bit too big IMO), scrollbars are thin (perhaps too think for libyui) and everything has a clear border. Also no scrolling areas inside scrolling areas, which is always annoying. [0] https://news.softpedia.com/images/reviews/large/debianinstallation-large_007.png https://news.softpedia.com/images/reviews/large/debianinstal... [1] https://documentation.suse.com/sles/15-GA/html/SLES-all/images/yast2_ncurses_inst.png https://documentation.suse.com/sles/15-GA/html/SLES-all/imag...

dahfizz 4y ago

This is really cool! I was impressed by the demo. I would be sad to see this replace a more "traditional" cli/tui, but for highly complex command line applications like qemu this is really awesome!

mixmastamyk 4y ago

I like this, seems to be the answer to the promise of Urwid. Unfortunately the main developer of which left for a long time once it hit 1.0. It was enough to build a widget toolkit, but didn't get proper widgets implemented for long enough that I lost track. I wanted to build an CUA terminal editor with one of these for decades but micro is recently good enough. So am cheering on in spirit.

rochak 4y ago

I love TUI and CLI based tools that keep me in my terminal as I have started to dread web applications more and more with every passing day. For obvious reasons, these tools have a better and more consistent UX since they need to rely on keyboard a lot more and are catered to more tech minded people. Not to mention the fact that they help avoid getting distracted by the endless ocean that is the internet.

thrown_22 4y ago
This framework, and every other one like it, is removing everything you liked about the terminal and turning it into a slightly less cluttered web browser. Give it 10 years and it won't be less cluttered.
- rochak 4y ago
  Well, good part is that I get to choose what I like and stick to those. I’m a big fan of Vim, Tmux, Vifm, Lazygit and look forward to what the future holds.
  - thrown_22 4y ago
    Until there's a coup, Moolenaar gets kicked out, a new bunch of people you've never heard of take over and run the project into the ground all while telling you you're doing it wrong. It happened to GTK, it will happen to you too.

tambourine_man 4y ago

Every time I see that scrolling demo my jaw drops. It never gets old. I've been using terminals for too long and the expectation of what should be possible is engrained deep. I want tmux to scroll and have hover states like that.

lilyball 4y ago

A key weakness of TUIs is the complete lack of accessibility. Everything is characters arranged for the eye to see, there's nothing at all for screen readers to use to extract semantic meaning.

trebbble 4y ago
I'm having trouble imagining how to solve this in the terminal itself—there a way to pass information to a screen-reader via some kind of side channel?
- lilyball 4y ago
  Terminals are GUI apps. In theory there could be a protocol for telling the terminal everything it needs to know for accessibility, and then convincing all terminal emulators to actually implement this, but it sounds like a nightmare.
stjohnswarts 4y ago
Very true, I don't even know how it would be possible without OCR that's "smart" about regions or a universal library in use that presented a way for software to see "what's going on" (pretty much a DOM equivalent)
xavdid 4y ago
Presumably command output with no chrome at all (only text content) would work well in a screen reader. So, I'd think the most accessible thing (today) would be to have an escape hatch to strip the output to its bones. Someone else who knows more about accessibility may know more though!

cbm-vic-20 4y ago

Most of these modern TUIs don't work on real "glass" terminals. Sure, nobody uses them anymore. I asked one of the Charm developer relations people if their stuff worked on old-school terminals like the VT-420, but they'd never even heard of that, didn't know what it was. Of course, the VT-420 came out before they were born, but still...

azinman2 4y ago
Do you use a VT-420?
- cbm-vic-20 4y ago
  I do! I usually have it connected to a Raspberry Pi and use it mostly for IRC, but also for retroprogramming projects.
- indymike 4y ago
  I used to keep a Zenith Z-29 terminal around that I bought (in new in the box condition) at a college surplus sale. I loved the keyboard on it and say what you will, green monochrome was really easy on the eyes (especially versus pre-super vga color screens). I used the Z-29 with a debugging card (it had a serial port) and when Linux took off, I used it as a terminal. It did well until the mid 00's when everything started expecting unicode support.

viksit 4y ago

Interesting other library - React for the terminal. Allows you to build the UIs using familiar web techniques and even has react dev tools! https://github.com/vadimdemedes/ink https://github.com/vadimdemedes/ink

sowbug 4y ago

> Unicode art is good This use case is crying out for a Textual-based ASCII art editor.

asciimov 4y ago

Seeing the amount of y’all excited about the guification of the terminal makes me concerned. I get it, this is a reaction to the appifying the browser. Please don’t turn to the terminal as a panacea for browsers. I don’t want my cli apps to suddenly be colorful or worse have css. Go back to making native apps, they are significantly better at doing interfaces than a terminal emulator. /rant

nixpulvis 4y ago
Exactly. Don't forget the UNIX philosophy. We build composable programs for the good of other use cases.
robomartin 4y ago
Having just delivered a “quick” console-based app to run a hardware product we manufacture, I fully sympathize with your comment. I have been coding for about 40 years. I can’t even remember the number of advanced text-based applications I wrote way back when that was it. Full menus, trees, scrolling regions, pop-up dialogs, color, even mouse input when it became available. As they say, ‘been there, done that. I decided to go console-based this time to roll out something quickly. We are working on a full GUI app, which was not going to be ready on time. Well, I put “quick” in quotes above because it was far from quick. I guess I forgot how much work these things can be. And, to your point, how much you end-up reinventing a perfectly good wheel. In retrospect, I should have told our customer to wait another week and deliver a far more capable product using wxPython. Lesson learned. Again.

hipjiveguy 4y ago

Terminals aren't "interactive prompts". They're requests. All requests need to be iterated on, in real time. So no one asks the perfect question immediately - it takes attempts, where the answer is no, or failure. So how fast we can interpret what the answer a terminal gives us is important. And a picture, or immediate visual interpretation, is worth more than a thousand words.