Should hidden widget keep the focus ?

[lisael]

To illustrate the issue, get my branch and run the either example (the branch is misnamed, I'm not sure it's a bug, now. I thought it was because of the storm of TimerEvent I kept recieving, without a visible focused widget):

cd /tmp
git clone [email protected]:lisael/druid.git
cd druid/druid
git checkout buggy_focus_on_either
cargo run --example either

the code

• click on [Edit 1] -> the textbox appears
• start typing in the textbox
• click on [Edit 1] -> the textbox becomes a label
• keep typing -> the label is still updated

I understand that this can be desirable, but it's surprising, and somewhat annoying because it's not easy to change the focus in update(...), as the UpdateCxt has no method for this.

Ideas:

1. add a ctx method to release the focus unconditionally
2. add a lifecycle event on widget show/hide (well... the LifecycleCtx can't change the focus, but at least it can submit a command)

[cmyr]

no, I think this is a bug. the hidden widget in Either should not be interactive.

My first thought is that Either should check to see if a child has focus when it changes children, and it should handle resigning if needed?

[lisael]

I tried to do that, checking is just self.current_widget().has_focus(). The harder part is I couldn't find a way to just drop the focus without using Commands sent to the children, so they can sort this out in their respective event(...). Maybe it's the only way? Maybe I'm missing something (quite new to druid...)?

[xarvic]

I think calling children_changed() in Either when switching the widgets should suffice.
This was the reason for #1724, but i forgot to update the docs.

[lisael]

@xarvic It suffice, indeed. Thanks! I send a PR, for this.

[xarvic]

That was quick :)