Feature Suggestions

[willmcgugan]

If there is a feature you really want to see in Rich TUI, post it here!

[graingert]

I'd love to see trio support

[tomchristie]

I'd be motivated to help textual bring in trio support.
Is this something you've crossed paths with much @willmcgugan / any existing motivation here without external prodding?

(My ideal stack here is being able to run neato raspberry pi devices with nifty textual apps, with trio for concurrency, and httpx for networkingy bits.)

[willmcgugan]

Things have moved on a lot since this post!

We're in a better position to tackle this, now that the internals have stabilized. In all honesty though it feels low priority. There are a lot of things that folk are asking for in Textual, but very few are asking for this. And my concern is that we break things for users that don't care about such things.

If it could be done in a way that wouldn't impact the user experience and performance in any meaningful way, I wouldn't have any objections. Especially if you were helping, Tom!

[tomchristie]

And my concern is that we break things for users that don't care about such things.

Your exposure here looks fairly modest, a non-API impacting switch to anyio is probably realistic.

In all honesty though it feels low priority. There are a lot of things that folk are asking for in Textual, but very few are asking for this.

This doesn't surprise me.
Nonetheless I'd advocate strongly for trio to anyone looking at async concurrency in Python.

(The trade-off in ecosystem support is the one sticking point.)

[willmcgugan]

No objection then.

There was an attempt, but I think Textual was moving too fast to keep up at that point.

BTW I was assuming you are advocating using AnyIO to get trio support?

[tomchristie]

BTW I was assuming you are advocating using AnyIO to get trio support?

In this instance, yes.

[wireboy5]

Have you considered an API similar to FastAPI or flask? I understand that those are web servers, but an API like that may fit this project. For example, a refractor of examples/simple.py:

from rich.markdown import Markdown

from textual import events
from textual.app import Textual
from textual.widgets.header import Header
from textual.widgets.placeholder import Placeholder
from textual.widgets.window import Window

with open("richreadme.md", "rt") as fh:
    readme = Markdown(fh.read(), hyperlinks=True, code_theme="fruity")

app = Textual()

app.bind({
    "q": "quit",
    "ctrl+c": "quit",
    "b":"view.toggle('left')"
})

@app.on("startup")
async def on_startup(event: events.Startup) -> None:
    await app.view.mount_all(
        header=Header(app.title), left=Placeholder(), body=Window(readme)
    )



app.run()

This could also be implemented to work like so:

from rich.markdown import Markdown

from textual import events
from textual.app import Textual
from textual.widgets.header import Header
from textual.widgets.placeholder import Placeholder
from textual.widgets.window import Window

with open("richreadme.md", "rt") as fh:
    readme = Markdown(fh.read(), hyperlinks=True, code_theme="fruity")

class App(Textual):
    def __init__(self):
        self.bind({
            "q": "quit",
            "ctrl+c": "quit",
            "b":"view.toggle('left')"
        })
    
    @on("startup")
    async def on_startup(self, event: events.Startup) -> None:
        await self.view.mount_all(
            header=Header(self.title), left=Placeholder(), body=Window(readme)
        )

app = App()

app.run()

This would just help to make things less hard-coded and more dynamic. For example: if the user wanted to use app.on_startup for something else.

I was also thinking maybe use a bind function instead of the KEYS variable that can also bind at runtime, in three variants:

# Dictionary of key to event
app.bind({
    "q": "quit",
    "ctrl+c": "quit",
    "b":"view.toggle('left')"
})

# List to events
app.bind(["q","ctrl+c"], "quit")

# Key to event
app.bind("b", "view.toggle('left')")

This would make adding and removing keybinds at runtime much easier. (At least, that is what I feel)

All in all, I am very excited to see this project, and wish you much luck and happy coding. 😃

[wireboy5]

Oh! I also almost forgot. I do not know if it already works like this, but is there/will there be support for mounting textual apps inside of other textual apps?

Also, I know most of this is polishing stuff, but these were the first things that came to mind when I looked at the project. 👍

[willmcgugan]

I prefer the Class based API for this. Events don't quite map to routes in a web server. Routes can grow indefinitely, but there will only ever be a finite number of events.

I might implement a bind function, although wouldn't expect it to be used much. Binding is rarely that dynamic. You set it once on startup and never change it. The exception would be if you are loading bindings from a configuration file on startup.

I considered a decorator approach, but decided against it. I don't see much benefit in having an event handler named in a different way. What would you call a key handler other than "on_key"? Ditto "on_startup". Adding @on("startup") just creates repetition. I think the "convention over configuration" approach works better here.

I hadn't considered mounting apps inside apps. It should be possible though. I can already think of some interesting use cases, so thanks for the suggestion!

[wireboy5]

Thanks for the reply!

Routes can grow indefinitely, but there will only ever be a finite number of events.

What do you think about user defined events? And keys can be bound to these events? So instead of using "view.toggle('left')" you could use "toggle_left_panel". Just a thought.

I considered a decorator approach, but decided against it. I don't see much benefit in having an event handler named in a different way. What would you call a key handler other than "on_key"? Ditto "on_startup". Adding @on("startup") just creates repetition. I think the "convention over configuration" approach works better here.

I agree, it just sprang to mind because I have seen some other frameworks use this format.

Awesome project, and good luck!

[willmcgugan]

The action system allows for custom actions, which lets you bind keys to methods beginning with action_. For instance, here's the view.toggle action:

    async def action_toggle(self, layout_name: str) -> None:
        visible = self.layout[layout_name].visible
        self.layout[layout_name].visible = not visible
        await self.layout_update()

but you could also define an action on app like this:

async def action_toggle_left_panel(self) -> None:
    ...

I'm going to flesh out that system, and allow widgets to emit events that can be caught by a parent widget.

[ksdaftari]

To add to discussion in terms of binding, one way that could think of dynamic binding is if app allowed to changed the shortcuts while using app (rather just configuring for app start up). Obviously Likely fine if change took affect when restarting app, but being able to do in session could be nice

[1dancook]

Would love to see a scrollable list view. But, to make it really awesome the implementation hopefully would be something like Rich tables.

Along with that, a few thoughts:

• being able to define what the visual selection looks like
• sticky headers for columns?
• methods and properties to interact with the selection
• I would expect that apart from scrolling the list with keys, I can use some defined key mappings to do some function with the selection

[willmcgugan]

Absolutely, tables are a killer feature.

[Cvaniak]

I was looking for scrollable list view and as I see this is in Backlog now. So for anyone who will be looking for something in the mid time I created hacky widget here.
It is not in pip because I think that official solution will be much better. I also have not create fork because I don't think that I understand Textual enough to write clean and style consistent code with rest of the project. (but if it will help I can try)

[P403n1x87]

I'd love to see support for resourceful TUIs in ways similar to https://p403n1x87.github.io/the-austin-tui-way-to-resourceful-text-based-user-interfaces.html or https://github.com/salt-die/nurses so that I don't have to maintain my own framework.

[Etzeitet]

I would love to see ready to use widgets, such as Menus, Forms (possibly with validation hooks), and popup dialogs.

We've been using npyscreen as it has those features, but that package hasn't been updated in years and we're looking to move away from it. rich-tui is looking very promising!

[willmcgugan]

Absolutely. There will eventually be a builtin library of widgets to cover most use cases.

[timfi]

Hi Will, I posted this as an Issue before I noticed this discussion… 😅

One widget I commonly use in many different contexts is some sort of tabbed container. I'm willing to open a PR for this myself, but I thought it might be nice to first discuss the API for it.

I'd expect the following usage pattern:

class MyApp(App):
    async def on_mount(self, event: events.Mount) -> None:
        tab1 = Tab("First Tab Label")
        # ... add some widgets to tab1
        await tab1.view.dock(someWidget())
        await tab1.view.dock(someWidget())
        await tab1.view.dock(someWidget())
    
        tab2 = Tab("Second Tab Label")
        # ... add some widgets to the tab
        await tab2.view.dock(someWidget())
        await tab2.view.dock(someWidget())
        await tab2.view.dock(someWidget())
        
        tabs = Tabs([tab1, tab2])
        await self.view.dock(tabs)

And I'd expect the output to look similar to this:

┌─────────────────┬──────────────────┬─────┄┄┄┄┄┄┄┄┄┄┄────┐
│ First Tab Label │ Second Tab Label │                    │
├─────────────────┴──────────────────┴─────┄┄┄┄┄┄┄┄┄┄┄────┤
│                                                         │
│         [ Content of selected Tab ]                     │
┆                                                         ┆
┆                                                         ┆
│                                                         │
└──────────────────────────────────────────┄┄┄┄┄┄┄┄┄┄┄────┘

With the small difference of the selected being highlighted somehow, be it bold or underlined or italic or whatever.

What are your thoughts on something like this?

[timfi]

Good to know that this will be made easier in the future! But I think I'll have a go at it now (even if just for the challenge… 😅 ) and if I get something satisfactory I'll drop a PR for it. 😄

[timfi]

Alrighty! I got something of the ground that looks half decent. 🥳 I'll try and clean it up a bit and open a PR for some discussion on it some time tomorrow. 😴

[timfi]

@willmcgugan Not quite done refining things yet, but for a first look you can have a look at this commit: timfi@234567b

[timfi]

I'm almost done, the only problem that I am having write now is that whack spacing of the tab handles…
timfi@2f94ea0

[timfi]

Done! 🥳

[USLTD]

@willmcgugan,
I have a feature suggestion for Textual. I don't know if it exists yet or not but if not why don't add hyperlinks? One which will open hyperlinks on click, like HTML's ? Or add JavaScript's and HTML's feature onclick for each widget/text/class/etc? Also second suggestion is to add more widgets like Graphs (using ASCII or Braille characters) and Canvas (using Drawille library).
Some TUI libraries written in another languages have them so I think it will be great to add those to Textual too.

[BillScherer]

I've used the Sparklines package with Rich, and that works well for simple, yet useful charts; I expect it will work with Textual too, I just haven't tried it yet.

[willmcgugan]

Links do exist currently in Textual. You can mark up text, detect clicks, and handle as required. I'll be expanding on that in the future.

There will be plots and graphs in the future.

@BillScherer yep, if it works in Rich, it will work with Textual.

[dissolved]

I'd like to see argument parsing including robust config file support. It will probably be one of the first things I do on my own assuming I move forward with using Textual for my project. I will try to do that in a way such that I can extract into a PR for Textual, but wouldn't want to duplicate effort if there are already plans to do this and/or explicitly wishes to keep that as something to be done outside of this framework.

[ksdaftari]

Don't know if this as much feature, but as community grows around textual imagine many will create their own reusable widgets. With this wondering if there any community standards and such we want to set (even if simple things like repo naming conventions, etc)

Thinking like what see from some community aspects like see in https://github.com/streamlit/streamlit where they have like streamlit gallery, component templates, streamlit repo readme badge. Another community additions to derive inspiration from is possibly pytest plugins

[willmcgugan]

Yeah, building community will be important. Streamlit have done that very well, so we can certainly follow their lead.

[ksdaftari]

@willmcgugan awesome. I wonder if also given the idea of using widget as classes is very close to idea way flutter (https://github.com/flutter/flutter) organizes its apps/code, if there is something to learn from there and that community?

[USLTD]

@willmcgugan,
Since textual is based on web technologies will you ...

1. ... add any scripting language runtime like JavaScript (ECMAScript) in browsers?
2. ... add HTML or any XML style markup language for easier TUI design?

[willmcgugan]

No to both. I’ll borrow web technologies where it makes sense, but Textual is a Python framework.

[USLTD]

No to both. I’ll borrow web technologies where it makes sense, but Textual is a Python framework.

Just thought that you too would implement 2nd option like some other TUI libraries, for example PyTermGUI

[ksdaftari]

I would assume, though not perfect converting html to markdown and using Rich's markdown rendering may help (eg package https://github.com/matthewwithanm/python-markdownify) though perhaps there is better way to go about this

[erdurano]

An image or thumbnail widget:
I previously mentioned to @willmcgugan about my intentions to implement a image widget in textual on twitter. I have some reservations and questions about specifics and thought that mentioning them here would be fruitful.

• Would it be satisfy the needs to implement a solution as demonstrated in this repo. It uses Unicode block characters and is sufficiently supported in all terminals that I can get my hands on yet (Windows Terminal and Konsole). If we need a pixel perfect solution, what would be the approach to picture consuming and transforming to Renderable type implementation look like?
• Widget protocol is sufficiently plain and I'm able to use it to implement the widget as is. But do we need a Image renderable type in Rich also? Must the work begin there?
• Wherever the solution is implemented, image file consumption would require pillow as a dependency. Does addition of such a library create a foreseeable problem? If so, what would be the alternate library and/or solution.
• Should this implementation be based on the main branch or css? This is obviously irrelevant now 😁

[samontoforce]

An terminal prompt being automatically generated based on a JSON schema would be great!

[mgaitan]

a SubprocessWidget to be able to replace tmux-like interfaces with ad-hoc textual apps.