8 ms·

A year of building for the terminal

278 points by willm 4y ago

cnt-dracula 4y ago
Wow, I used to like midnight commander a lot but moved away from it. Seeing things like that being built relatively easily makes me want to try using this for my personal project! Good work.
kredens 4y ago
cool! something like this for golang?
- eliaspro 4y ago
  Check out the Charm libs by https://charm.sh/ https://charm.sh/
inshadows 4y ago
[dead]
kjcondon 4y ago
This is an interesting framework, it's refreshing in that you don't need to bootstrap a whole web browser (electron) to build a user interface. I don't really see it's use case though, mostly cli is used for either: A) Ability to run in automated environments (e.g CI) - think aws cli B) Interop, think piping data from grep to xargs C) Hacking - writing a script quick and dirty to just get a job done I'd have thought if I was investing enough time to think about user interface, I'd just build my tool in Qt/GTK/JavaFX/Electron etc Though I can see the argument that if I was building an app with keybinds as controls rather than mouse primarly, probably a framework like this would be the way to go.
- almostjson 4y ago
  The uses for the terminal outlined are pretty limited. These are kind of the use cases I would expect from an average use that runs scripts or does occasional scripting work. It doesn’t really take into account more advanced users who do practically live in the terminal and do all the things outlined in the article (use a file browser from within a terminal) The target users here are pretty clearly them. It’s pretty hard to make usable tuis because the libraries kinda suck or are ancient - this project seems to be looking to change that. I’d even argue that the reason more people don’t use TUIs as much as GUIs is because TUIs aren’t always as intuitive or user friendly. Hopefully this helps that and makes them easier to build usable intuitive guis
- vageli 4y ago
  Have you ever heard of the curses library? There are use cases where you want to provide a graphical interface of sorts to a cli program. https://en.wikipedia.org/wiki/Curses_(programming_library) https://en.wikipedia.org/wiki/Curses_(programming_library)
- __MatrixMan__ 4y ago
  I spend a lot of time with k9s, a TUI, and if there's a browser based or native GUI version, I don't care. Terminals provide a uniform experience everywhere, more or less, and they compose better than browser apps. I can run tmux in asciinema and from there I can ssh elsewhere and use k9s. fzf and my zsh history make it so that it requires a few keystrokes to do anything (contrast this with being at the mercy of several conflicting designer opinions). A bunch of browser tabs is a comparatively clunky experience. If web or native GUI apps interoperate, it's because their authors had a conversation. Terminal apps interoperate by accident.
- jrmg 4y ago
  Though I can see the argument that if I was building an app with keybinds as controls rather than mouse primarly, probably a framework like this would be the way to go. Those old terminal apps that used to be used in banks, car hire places, airports, pharmacies and the like were _extremely efficient_ to use when you got to know them. Like, anything could be done with a few muscle-memory keystrokes. I always think of them when I’m in a line and an employee is busy peering and mousing around. I’m not sure how you could convince a company to go back to something like that though - it just _seems_ so unintuitively unapproachable at first. Maybe if you got a few high profile clients and they could publish how much more efficient they were (presuming they were)?
- leejoramo 4y ago
  I am someone who used micro-computers such as TRS-80, Apple ][, CP/M and early MS-DOS PC's. I used VisiCalc, MultiPlan, the original MS Word, dBase and many more. One of the most significant pain points with such apps was the lack of stand UI and keyboard conventions. One of the revolutions of the Macintosh was not just the GUI and Mouse, but the standard visual UI and keyboard shortcuts. Borland's Turbo Vision almost got us these features for TUI, but it was too late. I am glad to see people taking another crack at it. So let's make this TUI consistent with the conventions of your preferred GUI. I personally prefer macOS, but I am currently logged into to Windows 10 and KDE Neon. I spend most of my day in VSCode, with lets me configure it any way I want to.
- troyvit 4y ago
  I worked for a company that needed a bunch of tools developed quickly for internal support and implementation teams. We didn't have the authority or the time to build many web apps but it was super easy to set up a git repo with a bunch of cli apps for the teams to use. Everybody picked it up pretty quickly and felt pretty cool using the terminal to accomplish awesome things.
modernerd 4y ago
Has TUI accessibility improved at all? Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.
- sekao 4y ago
  I think we will need new standards here, because terminal emulators currently don't have any semantic information about what TUI programs are rendering. Browsers have the benefit of HTML to know this is a button, and that is a paragraph. A terminal is an unstructured grid of characters. The best we can hope for is for terminal emulators to use heuristics or AI to make sense of what TUI programs are rendering.
- willm 4y ago
  Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that. On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.
  - sekao 4y ago
    The browser target sounds neat. Do you plan on running the python in web assembly, or would it be a client/server design?
    - willm 4y ago
      Client / server initially. The app "runs" remotely with a JS front-end.
  - samwillis 4y ago
    I'm intrigued what the planned architecture is for the web front end. I'm guessing WebSocket back to a persistent process on the backend/server? So all operations happening via the websocket connection. Only the GUI in the browser? I bit like Phoenix LiveView. This would be a really interesting toolkit for building real-time UIs for remote processes.
UweSchmidt 4y ago
The terminal still has and always will have great potential as the glue that holds all computing together. Users refine their skill in a few, interoperable and flexible standard tools, and any command that turns out to be useful can immediately be part of a script that automates and simplifies this task forever. It all hinges not necessarily on more fanciness in the terminal, but on the availability of data to work on, on other systems to open their data to the terminal in some way. Many SAAS tools have no interest or incentive to do that; is the trend going away from data available the terminal? Example, Kibana and Splunk are silos that provide powerful ways to analyze logs - what else could you possible want more? Well, even the most sophisticated logfile queries can be repetitive, and those advanced search patterns could be distilled into a script that follows the user's hunches, add a bit of an ad-hoc regression test, correlate it with data from elsewhere, take user input from log files and use it in automated tests, maybe feed it all into a terminal based statistical analysis tool? I don't see myself doing any of that, the devs want a clickable link to the relevant Kibana and they are getting that. More colors in terminals are nice but is it enough to make a difference?
- zokier 4y ago
  > The terminal still has and always will have great potential as the glue that holds all computing together. Users refine their skill in a few, interoperable and flexible standard tools, and any command that turns out to be useful can immediately be part of a script that automates and simplifies this task forever. But the topic here is exactly the sort of framework whose apps are not particularly easily scriptable and integratable in typical shell-driven workflows.
pjmlp 4y ago
Looks like I am reading an UNIX magazine article back in 1992.
sebosp 4y ago
I've been playing around rust generative art (nannou) and shader toys on top of alacritty to experiment with other types of visual feedback and other types of interactions in the terminal, not just at GPU level, granted early stages make it convoluted but IMHO still bearable, https://github.com/sebosp/chartacritty https://github.com/sebosp/chartacritty
ryanianian 4y ago
How does Textualize make money? I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components. Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.
- willm 4y ago
  We were funded with Venture Capital. Which means full-time developers for the foreseeable future. But its worth pointing out that both projects existed for a long time before funding.
  - thejosh 4y ago
    And how do they see themselves getting money back? Is there a plan for paid subscriptions or something in the future? Not trying to be snarky or anything -- generally curious! I love the project.
    - willm 4y ago
      At some point next year, we will be working on a web service that puts Textual apps online. Completely opt-in, but it will allow you to serve Textual apps on the fly. There are various add-on services, like authentication, we can charge for. Plus a generous free tier.
- pipo234 4y ago
  I think ultimately, the idea is some sort of freemium model where the TUI is free, but usage as a web UI is will cost extra(?)
  - willm 4y ago
    Kind of, yeah. But there will also be a generous free tier.
goffi 4y ago
Textual looks nice. I've been a happy Urwid user for years, can someone with experience with both can do a quick comparison? Urwid development seems stalled (no commit for 6 months). Is it now possible to embed a terminal as a widget with Textual (with Urwid it's possible)? I'm wondering also how Rich compares to something like Python Prompt Toolkit.
enricozb 4y ago
It's not quite ready yet, but I'm writing something similar for Rust [0]. It's much more similar to React (with respect to components, and hooks), and the DSL is inspired by SwiftUI. Disclaimer: Version 0.6.x has a pretty severe flaw where the constraints around hook order are way too strict, and this also prevents conditional renders [1]. I'm working on a full rewrite which will be released as version 0.7.0, which exists on github as a branch right now [2]. Docs also exist for an alpha version of 0.7.0 [3]. [0]: https://docs.rs/intuitive/latest/intuitive/ https://docs.rs/intuitive/latest/intuitive/ [1]: https://github.com/enricozb/intuitive/issues/4 https://github.com/enricozb/intuitive/issues/4 [2]: https://github.com/enricozb/intuitive/tree/0.7.0 https://github.com/enricozb/intuitive/tree/0.7.0 [3]: https://docs.rs/intuitive/0.7.0-alpha.0/intuitive/index.html https://docs.rs/intuitive/0.7.0-alpha.0/intuitive/index.html
alganet 4y ago
This is great work
distcs 4y ago
Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right? Now I am not someone who would ask creators not to build something new because something like it already exists. By all means build new stuff and create new tools. It providers options and choice for user. So I fully support work like this. But I also ponder about user behavior. New users who flock to the modern terminal tools need to learn new keybindings, new shortcuts, new workflows. Yet they are willing to invest that time in learning these modern terminal tools. But many of the same users are averse to investing that time in Emacs. Why is that? What explains this? EDIT: Downvoters, care to explain what about this comment violates this site's guidelines? My comment is an honest question. You can post comments and explain if you disagree with my premise. But downvoting isn't helping me learn anything.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- rmorey 4y ago
  I’m not sure emacs is a good comparison here - Emacs is a complete environment and set of capabilities, whereas this is a library/toolkit for Python, much smaller/ more specific scope. I think it may be possible to take a python script, and create a UI for it in emacs, but I think the goal here is an python-native solution to turn a python script into a TUI
  - distcs 4y ago
    > Emacs is a complete environment and set of capabilities But so is the shell and the terminal and yet new young folks are much more willing to try out shell+terminal tools than Emacs+packages. Your comment describes the difference between this toolkit and Emacs perfectly from a dev POV and what you say makes complete sense. But I was pondering from user POV. I mean when devs use this library/toolkit and create terminal apps, I am sure those terminal apps will find many enthusiastic users. Many of the same users would not find themselves so enthusiastic if Elisp devs provided the same tool to them as an Emacs capability. You see my point? I don't know why this difference in attitude towards terminal tools and Emacs tools exists. Is it because of the reputation of Emacs being old? Or its reputation of unusual keybindings?
forrestthewoods 4y ago
Looks nice. But I’m not sure it’s worth the effort to build a “heavy” app in a TUI over a native app in Dear ImGui or similar. I’ve used Araxis Merge as my diff tool for over a decade. It’s great. I don’t think there’s significant value in reimplementing something in a TUI just for the sake of it. Nothing wrong with new tools to make building TUI’s easier. I just wish the examples were providing new capabilities rather than old capabilities in a very similar but slightly different form factor.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
tux 4y ago
First time I heard about Rich and Textual. Very impressive work, will definantly use it for something. Thank you to all involved.
- willm 4y ago
  Thanks. I will pass that on to the devs.
krunck 4y ago
"Please use animation sparingly." So... Doom?
tambourine_man 4y ago
I’m really exited about the work you guys are doing. That tab and easing animation is jaw dropping. I can’t shake the “that shouldn’t be possible in a terminal” feeling. In a good way. And git diff | dunk seems really useful. Keep going and posting.
- willm 4y ago
  Thank you!
carapace 4y ago
I went through a TUI phase recently and investigated a slew of these projects. In the end, I just used ncurses, there's no real point in using anything else. The biggest problem (that also affects Textualize) is poor or lacking documentation. But really the fundamental issue is that ncurses is all you need and it already covers all the edges and weird terminals etc.
- davepdotorg 4y ago
  How long ago did you check the documentation? As of October this year the first full set of docs were published, with more to come: https://textual.textualize.io/ https://textual.textualize.io/
  - carapace 4y ago
    I just checked my browser history and my latest visit was October 1st. I must have just missed it.
    - davepdotorg 4y ago
      Aye, that’ll be it then. The docs went live towards the end of October, with the release of 0.2.0 (which was a huge change over 0.1, adding the whole CSS approach). If you do decide to dip back by for a look you should hopefully find the documentation covers a lot now, with a really rich tutorial. Still plenty to add of course, it’s a work in progress, but I think we’re doing good for docs now.
      - carapace 4y ago
        I hate to sound negative but I'm still going to use ncurses. I'm not trying to slight Textualize (or any of the other fine TUI systems) when I say that, to me, they all seem like "fun toys". What I mean is that ncurses covers the terminal abstraction (glorified turd-polished teletype machine, literally an electric typewriter) and provides all the building blocks that make sense to provide. All these TUI projects then add an additional abstraction layer to essentially add a GUI toolkit on top. For my use case, it was more work to learn and use the additional abstractions than it was to implement the behaviour I wanted in ncurses. And this was true for every TUI system I tried, in every language I tried (OCaml, C, Nim, Python). The conclusion I came to was that TUI systems are essentially nerd toys (I mean that in an affectionate way), one gets "nerd-sniped" into making a TUI system and then sometimes it becomes a "real project" (Textualize has VC money?) but in ten or twenty years... ncurses will still be there, eh? (My lil tui side-quest got started when a terminal text editor project went by here on HN and I thought, "How hard could it be...?" Nerd-sniped by a classic: write your own text editor. The thing that saved me was that, as I said, I bounced off of the TUI sub-universe into the arms of ncurses, and then I realized that all my design ideas were basically vim, and that snapped me out of it. Whew! Close call!) From my POV the important thing is that the Textualize folks are having fun. (I don't mean that in a snark way, I'm sincere!)
jarbus 4y ago
I have a very specific use case: I want to have a UI interface around images generated by the kitty graphics protocol. Kitty, the terminal emulator, can render images in full resolution, which has been so helpful for viewing plots over ssh. I made a hacky ui for generating plots as I need them using prompt-toolkit, but having a proper TUI library that supports images would be so much nicer
- davepdotorg 4y ago
  This sort of thing is on the development roadmap. Also, some people have been building their own version of this with Textual already. Few days ago someone was showing off a Textual app they’d built that would play video - using the kitty protocol IIRC.
blooalien 4y ago
@willm Textual (and Rich) freakin' rock! Thank you so much for your hard work makin' them great!
- willm 4y ago
  De nada.
dlqx 4y ago
To be honest I am wondering what these people did not understand about terminals? A terminal is not meant to resemble graphical UIs with all those whistles and bells! Looks like I am the only one who is wondering :D ;)
- fragmede 4y ago
  Ugh no. Just because choose to use a keyboard-based interface doesn't mean I don't want things like colors and graphics.
- ibz 4y ago
  What is a terminal meant to do then and who says that? Actually I would argue that graphical UIs copied terminal UIs that existed first and in some cases they did not catch up even as of now. See file managers. There is Total Commander on Windows, which managed to surpass the old Midnight Commander in functionality and ease of use, but that's about it. Very hard to find a decent file manager on Linux or OSX that comes even close to mc.
  - deleted 4y ago
    [deleted]

278 points by willm 4y ago

Wow, I used to like midnight commander a lot but moved away from it. Seeing things like that being built relatively easily makes me want to try using this for my personal project! Good work.

kredens 4y ago

cool! something like this for golang?

eliaspro 4y ago
Check out the Charm libs by https://charm.sh/ https://charm.sh/

inshadows 4y ago

[dead]

kjcondon 4y ago

This is an interesting framework, it's refreshing in that you don't need to bootstrap a whole web browser (electron) to build a user interface. I don't really see it's use case though, mostly cli is used for either: A) Ability to run in automated environments (e.g CI) - think aws cli B) Interop, think piping data from grep to xargs C) Hacking - writing a script quick and dirty to just get a job done I'd have thought if I was investing enough time to think about user interface, I'd just build my tool in Qt/GTK/JavaFX/Electron etc Though I can see the argument that if I was building an app with keybinds as controls rather than mouse primarly, probably a framework like this would be the way to go.

almostjson 4y ago
The uses for the terminal outlined are pretty limited. These are kind of the use cases I would expect from an average use that runs scripts or does occasional scripting work. It doesn’t really take into account more advanced users who do practically live in the terminal and do all the things outlined in the article (use a file browser from within a terminal) The target users here are pretty clearly them. It’s pretty hard to make usable tuis because the libraries kinda suck or are ancient - this project seems to be looking to change that. I’d even argue that the reason more people don’t use TUIs as much as GUIs is because TUIs aren’t always as intuitive or user friendly. Hopefully this helps that and makes them easier to build usable intuitive guis
vageli 4y ago
Have you ever heard of the curses library? There are use cases where you want to provide a graphical interface of sorts to a cli program. https://en.wikipedia.org/wiki/Curses_(programming_library) https://en.wikipedia.org/wiki/Curses_(programming_library)
__MatrixMan__ 4y ago
I spend a lot of time with k9s, a TUI, and if there's a browser based or native GUI version, I don't care. Terminals provide a uniform experience everywhere, more or less, and they compose better than browser apps. I can run tmux in asciinema and from there I can ssh elsewhere and use k9s. fzf and my zsh history make it so that it requires a few keystrokes to do anything (contrast this with being at the mercy of several conflicting designer opinions). A bunch of browser tabs is a comparatively clunky experience. If web or native GUI apps interoperate, it's because their authors had a conversation. Terminal apps interoperate by accident.
jrmg 4y ago
Though I can see the argument that if I was building an app with keybinds as controls rather than mouse primarly, probably a framework like this would be the way to go. Those old terminal apps that used to be used in banks, car hire places, airports, pharmacies and the like were _extremely efficient_ to use when you got to know them. Like, anything could be done with a few muscle-memory keystrokes. I always think of them when I’m in a line and an employee is busy peering and mousing around. I’m not sure how you could convince a company to go back to something like that though - it just _seems_ so unintuitively unapproachable at first. Maybe if you got a few high profile clients and they could publish how much more efficient they were (presuming they were)?
leejoramo 4y ago
I am someone who used micro-computers such as TRS-80, Apple ][, CP/M and early MS-DOS PC's. I used VisiCalc, MultiPlan, the original MS Word, dBase and many more. One of the most significant pain points with such apps was the lack of stand UI and keyboard conventions. One of the revolutions of the Macintosh was not just the GUI and Mouse, but the standard visual UI and keyboard shortcuts. Borland's Turbo Vision almost got us these features for TUI, but it was too late. I am glad to see people taking another crack at it. So let's make this TUI consistent with the conventions of your preferred GUI. I personally prefer macOS, but I am currently logged into to Windows 10 and KDE Neon. I spend most of my day in VSCode, with lets me configure it any way I want to.
troyvit 4y ago
I worked for a company that needed a bunch of tools developed quickly for internal support and implementation teams. We didn't have the authority or the time to build many web apps but it was super easy to set up a git repo with a bunch of cli apps for the teams to use. Everybody picked it up pretty quickly and felt pretty cool using the terminal to accomplish awesome things.

modernerd 4y ago

Has TUI accessibility improved at all? Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.

sekao 4y ago
I think we will need new standards here, because terminal emulators currently don't have any semantic information about what TUI programs are rendering. Browsers have the benefit of HTML to know this is a button, and that is a paragraph. A terminal is an unstructured grid of characters. The best we can hope for is for terminal emulators to use heuristics or AI to make sense of what TUI programs are rendering.
willm 4y ago
Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that. On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.
- sekao 4y ago
  The browser target sounds neat. Do you plan on running the python in web assembly, or would it be a client/server design?
  - willm 4y ago
    Client / server initially. The app "runs" remotely with a JS front-end.
- samwillis 4y ago
  I'm intrigued what the planned architecture is for the web front end. I'm guessing WebSocket back to a persistent process on the backend/server? So all operations happening via the websocket connection. Only the GUI in the browser? I bit like Phoenix LiveView. This would be a really interesting toolkit for building real-time UIs for remote processes.

UweSchmidt 4y ago

The terminal still has and always will have great potential as the glue that holds all computing together. Users refine their skill in a few, interoperable and flexible standard tools, and any command that turns out to be useful can immediately be part of a script that automates and simplifies this task forever. It all hinges not necessarily on more fanciness in the terminal, but on the availability of data to work on, on other systems to open their data to the terminal in some way. Many SAAS tools have no interest or incentive to do that; is the trend going away from data available the terminal? Example, Kibana and Splunk are silos that provide powerful ways to analyze logs - what else could you possible want more? Well, even the most sophisticated logfile queries can be repetitive, and those advanced search patterns could be distilled into a script that follows the user's hunches, add a bit of an ad-hoc regression test, correlate it with data from elsewhere, take user input from log files and use it in automated tests, maybe feed it all into a terminal based statistical analysis tool? I don't see myself doing any of that, the devs want a clickable link to the relevant Kibana and they are getting that. More colors in terminals are nice but is it enough to make a difference?

zokier 4y ago
> The terminal still has and always will have great potential as the glue that holds all computing together. Users refine their skill in a few, interoperable and flexible standard tools, and any command that turns out to be useful can immediately be part of a script that automates and simplifies this task forever. But the topic here is exactly the sort of framework whose apps are not particularly easily scriptable and integratable in typical shell-driven workflows.

pjmlp 4y ago

Looks like I am reading an UNIX magazine article back in 1992.

sebosp 4y ago

I've been playing around rust generative art (nannou) and shader toys on top of alacritty to experiment with other types of visual feedback and other types of interactions in the terminal, not just at GPU level, granted early stages make it convoluted but IMHO still bearable, https://github.com/sebosp/chartacritty https://github.com/sebosp/chartacritty

ryanianian 4y ago

How does Textualize make money? I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components. Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.

willm 4y ago
We were funded with Venture Capital. Which means full-time developers for the foreseeable future. But its worth pointing out that both projects existed for a long time before funding.
- thejosh 4y ago
  And how do they see themselves getting money back? Is there a plan for paid subscriptions or something in the future? Not trying to be snarky or anything -- generally curious! I love the project.
  - willm 4y ago
    At some point next year, we will be working on a web service that puts Textual apps online. Completely opt-in, but it will allow you to serve Textual apps on the fly. There are various add-on services, like authentication, we can charge for. Plus a generous free tier.
pipo234 4y ago
I think ultimately, the idea is some sort of freemium model where the TUI is free, but usage as a web UI is will cost extra(?)
- willm 4y ago
  Kind of, yeah. But there will also be a generous free tier.

goffi 4y ago

Textual looks nice. I've been a happy Urwid user for years, can someone with experience with both can do a quick comparison? Urwid development seems stalled (no commit for 6 months). Is it now possible to embed a terminal as a widget with Textual (with Urwid it's possible)? I'm wondering also how Rich compares to something like Python Prompt Toolkit.

enricozb 4y ago

It's not quite ready yet, but I'm writing something similar for Rust [0]. It's much more similar to React (with respect to components, and hooks), and the DSL is inspired by SwiftUI. Disclaimer: Version 0.6.x has a pretty severe flaw where the constraints around hook order are way too strict, and this also prevents conditional renders [1]. I'm working on a full rewrite which will be released as version 0.7.0, which exists on github as a branch right now [2]. Docs also exist for an alpha version of 0.7.0 [3]. [0]: https://docs.rs/intuitive/latest/intuitive/ https://docs.rs/intuitive/latest/intuitive/ [1]: https://github.com/enricozb/intuitive/issues/4 https://github.com/enricozb/intuitive/issues/4 [2]: https://github.com/enricozb/intuitive/tree/0.7.0 https://github.com/enricozb/intuitive/tree/0.7.0 [3]: https://docs.rs/intuitive/0.7.0-alpha.0/intuitive/index.html https://docs.rs/intuitive/0.7.0-alpha.0/intuitive/index.html

alganet 4y ago

This is great work

distcs 4y ago

Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right? Now I am not someone who would ask creators not to build something new because something like it already exists. By all means build new stuff and create new tools. It providers options and choice for user. So I fully support work like this. But I also ponder about user behavior. New users who flock to the modern terminal tools need to learn new keybindings, new shortcuts, new workflows. Yet they are willing to invest that time in learning these modern terminal tools. But many of the same users are averse to investing that time in Emacs. Why is that? What explains this? EDIT: Downvoters, care to explain what about this comment violates this site's guidelines? My comment is an honest question. You can post comments and explain if you disagree with my premise. But downvoting isn't helping me learn anything.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
rmorey 4y ago
I’m not sure emacs is a good comparison here - Emacs is a complete environment and set of capabilities, whereas this is a library/toolkit for Python, much smaller/ more specific scope. I think it may be possible to take a python script, and create a UI for it in emacs, but I think the goal here is an python-native solution to turn a python script into a TUI
- distcs 4y ago
  > Emacs is a complete environment and set of capabilities But so is the shell and the terminal and yet new young folks are much more willing to try out shell+terminal tools than Emacs+packages. Your comment describes the difference between this toolkit and Emacs perfectly from a dev POV and what you say makes complete sense. But I was pondering from user POV. I mean when devs use this library/toolkit and create terminal apps, I am sure those terminal apps will find many enthusiastic users. Many of the same users would not find themselves so enthusiastic if Elisp devs provided the same tool to them as an Emacs capability. You see my point? I don't know why this difference in attitude towards terminal tools and Emacs tools exists. Is it because of the reputation of Emacs being old? Or its reputation of unusual keybindings?

forrestthewoods 4y ago

Looks nice. But I’m not sure it’s worth the effort to build a “heavy” app in a TUI over a native app in Dear ImGui or similar. I’ve used Araxis Merge as my diff tool for over a decade. It’s great. I don’t think there’s significant value in reimplementing something in a TUI just for the sake of it. Nothing wrong with new tools to make building TUI’s easier. I just wish the examples were providing new capabilities rather than old capabilities in a very similar but slightly different form factor.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

tux 4y ago

First time I heard about Rich and Textual. Very impressive work, will definantly use it for something. Thank you to all involved.

willm 4y ago
Thanks. I will pass that on to the devs.

krunck 4y ago

"Please use animation sparingly." So... Doom?

tambourine_man 4y ago

I’m really exited about the work you guys are doing. That tab and easing animation is jaw dropping. I can’t shake the “that shouldn’t be possible in a terminal” feeling. In a good way. And git diff | dunk seems really useful. Keep going and posting.

willm 4y ago
Thank you!

carapace 4y ago

I went through a TUI phase recently and investigated a slew of these projects. In the end, I just used ncurses, there's no real point in using anything else. The biggest problem (that also affects Textualize) is poor or lacking documentation. But really the fundamental issue is that ncurses is all you need and it already covers all the edges and weird terminals etc.

davepdotorg 4y ago
How long ago did you check the documentation? As of October this year the first full set of docs were published, with more to come: https://textual.textualize.io/ https://textual.textualize.io/
- carapace 4y ago
  I just checked my browser history and my latest visit was October 1st. I must have just missed it.
  - davepdotorg 4y ago
    Aye, that’ll be it then. The docs went live towards the end of October, with the release of 0.2.0 (which was a huge change over 0.1, adding the whole CSS approach). If you do decide to dip back by for a look you should hopefully find the documentation covers a lot now, with a really rich tutorial. Still plenty to add of course, it’s a work in progress, but I think we’re doing good for docs now.
    - carapace 4y ago
      I hate to sound negative but I'm still going to use ncurses. I'm not trying to slight Textualize (or any of the other fine TUI systems) when I say that, to me, they all seem like "fun toys". What I mean is that ncurses covers the terminal abstraction (glorified turd-polished teletype machine, literally an electric typewriter) and provides all the building blocks that make sense to provide. All these TUI projects then add an additional abstraction layer to essentially add a GUI toolkit on top. For my use case, it was more work to learn and use the additional abstractions than it was to implement the behaviour I wanted in ncurses. And this was true for every TUI system I tried, in every language I tried (OCaml, C, Nim, Python). The conclusion I came to was that TUI systems are essentially nerd toys (I mean that in an affectionate way), one gets "nerd-sniped" into making a TUI system and then sometimes it becomes a "real project" (Textualize has VC money?) but in ten or twenty years... ncurses will still be there, eh? (My lil tui side-quest got started when a terminal text editor project went by here on HN and I thought, "How hard could it be...?" Nerd-sniped by a classic: write your own text editor. The thing that saved me was that, as I said, I bounced off of the TUI sub-universe into the arms of ncurses, and then I realized that all my design ideas were basically vim, and that snapped me out of it. Whew! Close call!) From my POV the important thing is that the Textualize folks are having fun. (I don't mean that in a snark way, I'm sincere!)

jarbus 4y ago

I have a very specific use case: I want to have a UI interface around images generated by the kitty graphics protocol. Kitty, the terminal emulator, can render images in full resolution, which has been so helpful for viewing plots over ssh. I made a hacky ui for generating plots as I need them using prompt-toolkit, but having a proper TUI library that supports images would be so much nicer

davepdotorg 4y ago
This sort of thing is on the development roadmap. Also, some people have been building their own version of this with Textual already. Few days ago someone was showing off a Textual app they’d built that would play video - using the kitty protocol IIRC.

blooalien 4y ago

@willm Textual (and Rich) freakin' rock! Thank you so much for your hard work makin' them great!

willm 4y ago
De nada.

dlqx 4y ago

To be honest I am wondering what these people did not understand about terminals? A terminal is not meant to resemble graphical UIs with all those whistles and bells! Looks like I am the only one who is wondering :D ;)

fragmede 4y ago
Ugh no. Just because choose to use a keyboard-based interface doesn't mean I don't want things like colors and graphics.
ibz 4y ago
What is a terminal meant to do then and who says that? Actually I would argue that graphical UIs copied terminal UIs that existed first and in some cases they did not catch up even as of now. See file managers. There is Total Commander on Windows, which managed to surpass the old Midnight Commander in functionality and ease of use, but that's about it. Very hard to find a decent file manager on Linux or OSX that comes even close to mc.
- deleted 4y ago
  [deleted]