Open Uriopass opened 4 months ago
Widgets can currently request focus by using ctx.input.set_selection(Some(id))
from an event. TextBox
does this for an example. That API is a little bit clunky though and I don't think there's any way to access the input context from outside of a widget implementation.
I like both of the proposed APIs and I think they could work well together! The Dom::request_focus
API could replace the current selection API.
This proposal would probably require us to either move some input state into the Dom
struct itself, or to add some sort of pending requested focus change field to Input
that we could flush at the end of an update. I'm not sure what would be the better call. State being split across several structs was an early yakui design decision and I don't know if it's one that we need to uphold very strongly.
Instead of a pending requested focus on Input
, I think a pending requested focus on Dom
makes more sense as I feel this state belongs more to Input
?
I've done that at #146
Currently writing a simple chat. I'd like to be able to automatically focus the textbox when pressing "T" and the textbox appears. There appears to be some state about which widget is focused as there is
WidgetEvent::FocusChanged
.I was thinking of adding a method to the Dom with a widget id. Would that be a good API?
so you could do
could even be implemented on top of Response