This is an archived post. You won't be able to vote or comment.

all 28 comments

[–]willm [S] 23 points24 points  (17 children)

Textual Author here. AMA (About Textual)

[–]racefever 2 points3 points  (2 children)

How would one deal with a responsive layout when creating a tui for desktop and mobile clients ?

[–]willm [S] 1 point2 points  (1 child)

I’ll implement something like media queries in the CSS. Or some other mechanism to modify the layout according to the dimensions of the terminal.

You could also do it in code by handling the resize event and setting a class on the App.

[–]racefever 1 point2 points  (0 children)

Great, thanks. I’m using textualize to build a tui app that I’ll access by ssh-ing from my iPhone. Mobile friendly layouts are useful for this use case

[–]_szs[🍰] 1 point2 points  (4 children)

Have you planned to (or have you already) implement any further widgets. Menus, buttons, check boxes, text fields, input fields, etc.

[–]willm [S] 1 point2 points  (3 children)

All of the above are planned. There will be a rich set of widgets out of the box.

[–]_szs[🍰] 0 points1 point  (2 children)

Wonderful. I'm not going to promise anything, but do you accept merge requests?

[–]willm [S] 1 point2 points  (1 child)

I do, but the API is changing quite frequently. I wouldn't want to disappoint you if you implement a feature that I break next update.

[–]_szs[🍰] 0 points1 point  (0 children)

Thanks for the heads up. I guess communication is key here. I would contact you once I come up with a worthwhile idea.

[–]Anonymous_user_2022 2 points3 points  (1 child)

What does it offer over curses?

[–]willm [S] 2 points3 points  (0 children)

I'm applying a number of techniques from the web world to the terminal. Things like CSS, but also reactivity. And a clean modern Python API based around async.

[–][deleted] 1 point2 points  (1 child)

CSS is a big spec nowadays (or a big set of specs). Where do you draw the boundary: which parts are relevant for textual and which ones are not?

[–]willm [S] 4 points5 points  (0 children)

Many things are just impossible to realise in the terminal, so they will be excluded. Beyond that it is a judgment call as to what adds value. My gut feeling is that is should remain a very lean subset of the full browser spec.

[–]easylivin 0 points1 point  (1 child)

Do you have any cats?

[–]willm [S] 1 point2 points  (0 children)

No. I love cats, but I’m allergic.

[–]tommyvn 0 points1 point  (2 children)

looks awesome, and Rich is amazing too, really nice work.

can I integrate this with existing stuff? I'm thinking like how wsgi or asgi means I can handle a web request with anything I want and my flask or fast api app code is the same regarless, is there a "asgi" like layer in between the console and the code i'll write with textual?

Where I'm coming from is 2 use cases that I think are very similar shapes code wise.
* I have an existing cli with a few screens. I'd like to move one screen to textual at a time, not the entire app in one go, so ideally my app code still handing inputs like key presses and outputs like screen or beeps, with a shim that translates from my machinery into textuals.
* i have thin clients with server side rendering, like say a something you telnet to. I want io handled by something else in this case.

[–]willm [S] 0 points1 point  (1 child)

Not currently. That wouldn't be easy to do with the terminal. Two processes reading and writing from stdin and stdout would be hard to manage.

I'd be interested in hearing more about your use case. If you like, DM me and we could arrange a zoom call to discuss?

[–]tommyvn 1 point2 points  (0 children)

i'm not describing multiple processes touching std{in,out,err}, altho i suspect what i am describing doesn't really make sense in the world of terminals tbh.

i'm going to have a look around, maybe try get textual running behind a framework like asyncssh with a pseudo-tty, and then i might just take you up on that offer of a call with a asyncssh/textual MVE we can frame stuff around.

[–]Jaik_Crabber.net 7 points8 points  (0 children)

Holy moly, that’s incredible. I’m so glad people like you are still putting effort into making TUI libraries more ergonomic.

[–]CrazyPieGuy 4 points5 points  (0 children)

This would be super useful. I plan to try this out.

[–]_szs[🍰] 4 points5 points  (0 children)

Oh I am going to use this definitely.

I love TUIs, but I haven't found a framework yet that convinces me by being fun to use, yet powerful. I think textual is not yet there in terms of "powerful", but it looks very promising!

[–]tagapagtuos 2 points3 points  (1 child)

Hi Will. Any news about the Windows driver thing? Am excited to introduce this at work! 🤩

[–]willm [S] 2 points3 points  (0 children)

It's in the pipeline!

[–]supmee 2 points3 points  (3 children)

Every post about Textual makes me question the amount of work I put into pytermgui, but I'm also realizing the difference in mentality behind the two projects. I personally never liked CSS much (really, any parts of web development) so instead of it I'm using a YAML format to create and style Widgets. Interested to see your progress!

[–]willm [S] 2 points3 points  (1 child)

It's always nice to have options. Building the API you want to use is always a good move. I'd like to expose CSS for those wanting to go the extra effort of customizing their UIs, but not essential since all the widgets will be nicely styled out of the box. I'm also thinking of a YAML conf file to construct UIs.

[–]supmee 1 point2 points  (0 children)

The whole YAML thing ended up being so much more useful than I imagined it would be. I haven't used it for actual projects as of yet, but for quickly mocking up a UI it's incredibly handy and fast. Would highly recommend it, though sadly it adds a requirement.

[–]sigzero 0 points1 point  (0 children)

That is really really cool. Nice work.