Contextual/Dynamic/State-based/Changeable Bindings

[mzebrak]

I searched the entire history of issues and discussions and encountered related topics, but I did not find a specific answer that could work for my use case.

What I found:

• Contextual Key-Bindings #409 -> No answer.
• [Improvement] Add/expose API to update Footer's Bindings  #1057 -> "Bindings should be relatively static"
• Allow Binding descriptions to change #1410 and related PR WIP: Add an example of dynamic bindings #1412 -> Actually in textual 0.10.1, the given example doesn't work for me. It also focuses on changing the description which is not quite the answer for me as I would like to add/remove entire bindings
• Switch between multiple sets of bindings #1306 -> This one is pretty interesting and actually covers my case. Unfortunately the proposed solution of having relevant bindings at the widget level won't work in my case.

So we finally got to my case (which I don't think is that specific and I think a lot of state based apps will have a similar issue):

The application I am thinking of is a more advanced application based on two main states - ACTIVE / INACTIVE (something like logged in/ logged out).

1. Let's say that when the user starts the application - it lands on some dashboard with publicly available data. from here he should be able to log in (say under key binding F1, which will redirect him to the login screen where he can enter his credentials).

   So in the INACTIVE mode, for simplicity let's say that on the dashboard screen (this is important - a separate Screen, because the application will be quite complex and it is required to have multiple screens) we will have only a single key binding - "F1 Login"

2. When a user is already logged in, there is no "F1 Login" on the dashboard, and instead there is "F1 Logout". Additionally there might be some other bindings available for him (like F2 Transfer etc which would not be possible without logging in)

So instead of just changing the description of the key binding, I have to change its callback as well, and sometimes completely new bindings have to be created/old ones deleted.

The actual solution I'm thinking of is to have two separate Screens -> DashboardActive and DashboardInactive which will have their own bindings. All other contents will be identical, so it's not a perfect solution, it introduces a lot of redundancy, but let's say we can still fight it somehow by introducing some base class.

Is there a better solution to this problem? I took into account defining bindings only for the widget, but for them to appear, it must be focused, so it doesn't seem to help in this situation, because I would just have to move all the content of my screen to the top-level widget, where just in In this situation, it is probably better to create two separate screens.

[davep]

As you've identified, there's no firm plan yet, but I think we do want to make bindings a wee bit more dynamic in the future. For now though I think the approach I'd take is the one you seem to have settled on now: a couple of screens with a common base class.

[mzebrak]

Alright, it's fine. Thanks for quick reply.

[willmcgugan]

@mzebrak How would you want Textual to handle this at the API level?

[mzebrak]

@willmcgugan Sorry for late response. I would appreciate any way of simply affecting bindings. currently it is very difficult to do this because it forces multi-screen applications to use inheritance with a common logic. This creates a lot of boilerplate.

The interface may be similar to the mount method

self.bind(Binding(...))
self.app.bind(Binding(...))  # there should be possibility to affect global (App) bindings and current Screen bindings
self.bind_all(Binding(...), Binding(...))
self.bindings  # get list of bindings

or maybe even querying bindings so you can get the one from your context?

self.query_binding("f1").remove()
self.bind(Binding("f1", "else", "Something else"))

I'm open to anything, I just miss the opportunity.