Support focus/unfocus events for TextInput and possibly other focusable widgets

[lufte]

I've been using a patched version of TextInput in my app which supports subscribing to changes to its focus state with the help of two methods: on_focus and on_unfocus.

In my app, a sort of web browser with vim-like functionality, I listen to these events to enter or leave the INSERT mode. The mode my app is in determines some of its behavior, particularly what keyboard shortcuts are active and what to actually show on the screen. If the user (un)focuses a text input I want to know about it so I can change the current mode.

In #2019 it's mentioned that losing focus is a problematic event nowadays in Iced due to the possibility of loss of continuity between view invocations. I agree, I had to deal with it #1874, but I think this is a problem that exists despite focus/unfocus events. I had to work around it in a TextInput not because I cared about its focus events (not all inputs in my app can trigger a mode change), but simply because the widget was losing focus as the user wrote into it. So as I see it, one needs to be aware of the continuity problem even without this feature.

It may make sense, though, to wait until continuity is implemented with widget IDs to add these new events.

[hecrj]

For this use case, I believe a managed version of a TextInput would be helpful. By managed I mean a different TextInput widget that takes its internal State as an argument from the application state. This would be similar to the old stateful widgets, but the State will be actually updated in update.

This will allow you to query the focus state of the TextInput (State::is_focused) directly both in view and update without duplicated sources of truth that can go out of sync.

This idea of having a "managed" version for each widget is something we have discussed in the core team and should eventually happen. In the meantime, you could try exploring that idea with TextInput and its focus state and report back with your findings!

[lufte]

Would this imply losing the animated cursor?

[hecrj]

No. The Shell::request_redraw API can be accessed from Widget::on_event without any need to trigger any messages.