> 4. Using CSS for laying out a TUI app makes no sense (unless you are a web developer and have Stockholm syndrome from using it for web apps?)

Fun fact: CSS had, since CSS 2.0, the media type ‘tty’, for use in media queries targeting text browsers like links or lynx or such:

  @media tty {
    body {
      max-width: 80ch;
    }
  }

With the powers of flexbox and grid and a limitation on those new character-based lengths I could imagine an alternative future with TUIs in a CSS layout.

But afaik ‘tty’ has never been implemented and as such never been used. In CSS Media Queries Level 4 all media types outside of ‘all’ and ‘screen’ have been deprecated.

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

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

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

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

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

I'm not aware of Textual ever leaking memory. If there was a memory leak, I'd make it a priority to fix.

Ultimately though, I'm glad you built your TUI.

Related to #1 you mentioned, to me Textual looks just ugly - like if someone thought it wasn't enough for desktop GUIs to be infested with mobile phone UIs, it also has to be the terminal apps too.

Like, hell, their examples have some *HUGE* buttons, starting with a calculator app that is all buttons - who is going to click on those? The calculator-with-buttons barely makes sense for desktop GUI apps (it was helpful back in the 80s when everyone had a physical calculator on their desk to help see the metaphor of the "virtual desktop" and it is arguably helpful on touch screen devices today for obvious reasons, but on a machine with a keyboard it is superfluous), let alone TUIs.

If you want to see a TUI that actually looks good (though a bit too much on the fancy side, but it doesn't pretend to be something it isn't) check btop:

https://github.com/aristocratos/btop

>2. The async nature of the library is unpleasant. Can never be sure when/where your code will run.

>3. Lots of 'magic' Python variables and methods that you have to override, but there's no way to discover them in your IDE through the type system ...

>5. It seems to leak memory.

Welcome to Python. =)

what library did you end up using instead?

Exact same experience I had. I would also add that the CSS styling doesn't really work. And it's frustrating because I would prefer if it didn't work all time, but it seems to only not work some of the time and I can't figure out the algorithm of when it doesn't work.

I tried to use urwid too and gave up. Python needs a library as good as ftxui for C++

Okay, but what is the different library...?

> unless you are a web developer and have Stockholm syndrome

Reminder that “Stockholm Syndrome” is not only universally invoked as a dismissive, thought-terminating cliché, it was also literally invented out of a whole cloth for just that purpose, as a pretext for dismissing legitimate criticism by a person with significant responsibility for the decision being criticized.

I understand you mean no disrespect to the Textual author, but i would still like to know your comparable alternative...

Would very much like to know about the alternatives, please.

css might feel insane but not much than splatting ansi escape codes around bytes.

Agreed are there good tui library in haskell

Seems like a lot of the negatives are tied to Python.

There's a gallery for Textual: https://www.textualize.io/textual/gallery

And for Rich: https://www.textualize.io/rich/gallery

There's a list here: https://github.com/davep/transcendent-textual

I was like you and found out that you can actually remove the extra padding using CSS.

I'm not sure I understand your line endings issue. But we've had Textual working over SSH.

If you want to post an issue on the repo, I think we could resolve it.

"half the library" - half of textual, you mean?

Also - can you elaborate on how the CRLF vs LF broke your app? Give a code snippet as an example?

Are the CRLFs related to Windows? I’ve never encountered them anywhere else…

Seems to me that Textual is at v0.14.0?

Agreed in principe but we live in the real world.

GUI apps are ever more bloated and often aren't written for power users (many shortcuts etc). Sure they can have all those things, but they don't. Also, UI designers are really strong trend followers meaning their apps will waste a lot of screen real estate and are often white on light gray right now because that seems to be the current fashion.

Also running apps remotely with a simple and fast interface is often really a big plus.

At least for me, apart from all the other obvious reasons to use a TUI, a big part of it is the fact that it's so much easier to get a coherent and consistent user interface with TUIs compared to GUIs. Every GUI uses a different UI system and as such will look incoherent with other apps. Just take GTK vs Qt.The UI of my daily machine looks extremely coherent and most of that is contributed to most of my programs being CLI or TUI.

I am not a huge fan of the TUI(Graphical terminal application) But I do think the CLI(an App you control only via a command line) is the better interface method for many application. mainly because they provide the highest code ratio of any methodology. That is, you get more interface with less code using a cli than any other method

But one thing I love about terminal applications is how nice they work on remote sessions.

> anything you can do in a tui can be done better in an actual graphical window.

Almost certainly. But for whatever reason, most GUIs created happen to be really bad at the things that most TUIs I've used happen to be really good at, namely searchability, reflowability (mostly used to increase text size and change font face for legibilit), and keyboard navigation.

GUIs that nail these things are delightful. They're highly accessible and extremely efficient to use. But it also seems to me like the full power afforded by GUI toolkits leads a lot of developers to pour a lot of time and effort into other things (which matter less, at least to me, personally) while totally neglecting those aspects of their apps.

I’d suggest that the proliferation of software with many possible interactions adding features that let you invoke actions via a command-line like interface (see Ctrl+P command palettes etc) prove that there is a place for these sorts of interfaces. Using a mouse is inefficient, and there are only so many hot keys one can assign and learn.

I agree that terminals are fetishised a bit, and I personally find a mix of GUIs and terminals to be the most effective combination, but I think there’s something valuable in the interaction pattern.

The biggest problem with GUIs is that there is no reliable standard that works everywhere. The VT100 standard is 45 years old and will most likely work for the next 45 years. It is dead simple to implement GUIs (just write to stdout) and all those programs that use that protocol to render their GUI are immediately portable to almost every platform on the planet and work over the network via ssh without any additional need for programming.

Well, I don’t know about in general but I think this is the case for Emacs except maybe for some remote session use-cases.

pipe stdin.

one word: latency

What is Ctrl+e?

I mean, it should be the other way around

The top comment is several paragraphs of reasoned comment about the features the poster tried and found lacking in the library

If you have experience of the library, which I guess you do to arrive at your conclusion please share it - what was crap about the library. What context was your experience? What could be improved (even maybe the top posters decision - you can't improve it just try something else).

Try Harder. Please.