You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make it possible for TextInput to emit a message when gaining/losing foccus. #819
This could be useful when using iced with an existing wgpu application like in the integration example.
Imagine that the wgpu application is supposed to react to some keyboard inputs (for example W A S D to move the camera) and that the iced GUI on top of it has some TextInput.
It would be useful to know in the main loop if of the TextInput is focused so that, in that case the keyboard events would not be forwarded to the wgpu app but only to the iced GUI.
Currently this can be achieved by asking the iced GUI, to check the state of all of its TextInput but I think emitting a message would make it easier.
An event for gaining focus should be relatively straightforward to add. However, the losing focus one is trickier mainly because the focused widget can be removed from the widget tree anytime and I imagine users would expect the event to trigger in that case.
That said, if you want to know if a specific Event was captured by iced, you can always use UserInterface::update directly which returns a list of event::Status.
So I thought about this some more: An application, for example, a game, might want to keep track of which keys are currently pressed. If a TextInput gains focus it should be equivalent to all keys being un-pressed/released.
So I think its not sufficient to just forward the un-captured events to the application's input management. I think something like a TextInputFocused (or more generally a UiFocused event) might be super useful.
I don't think you need to propagate an unfocused event as well, but it might be necessary for other use cases.
I had a problem probably related to this, I wanted to close a window on pressing ESC but when the text input was focused the update event loop did not get the KeyPressed event.
I did find a workaround by listening to the KeyReleased event though.
I had a problem probably related to this, I wanted to close a window on pressing ESC but when the text input was focused the update event loop did not get the KeyPressed event.
I did find a workaround by listening to the KeyReleased event though.
Seems quite different from this issue. You seem to always want to receive the ESC event independent of whether a text input is focused, or do I misunderstand?
I had a problem probably related to this, I wanted to close a window on pressing ESC but when the text input was focused the update event loop did not get the KeyPressed event.
I did find a workaround by listening to the KeyReleased event though.
Seems quite different from this issue. You seem to always want to receive the ESC event independent of whether a text input is focused, or do I misunderstand?
yes, but as the textinput is the only thing present, listening for it loosing focus is also fine.
Activity
hecrj commentedon May 4, 2021
An event for gaining focus should be relatively straightforward to add. However, the losing focus one is trickier mainly because the focused widget can be removed from the widget tree anytime and I imagine users would expect the event to trigger in that case.
That said, if you want to know if a specific
Eventwas captured byiced, you can always useUserInterface::updatedirectly which returns a list ofevent::Status.kaimast commentedon May 6, 2021
How about a widget that that behaves like
Containerbut allows to handle events that are not processed by its children?Using
UserInterface::updateworks but seems to require re-implementing some of the functionality ofprogram::State.kaimast commentedon Jan 10, 2022
So I thought about this some more: An application, for example, a game, might want to keep track of which keys are currently pressed. If a
TextInputgains focus it should be equivalent to all keys being un-pressed/released.So I think its not sufficient to just forward the un-captured events to the application's input management. I think something like a
TextInputFocused(or more generally aUiFocusedevent) might be super useful.I don't think you need to propagate an unfocused event as well, but it might be necessary for other use cases.
(Please correct me, if I am wrong)
ModProg commentedon Oct 12, 2022
I had a problem probably related to this, I wanted to close a window on pressing ESC but when the text input was focused the update event loop did not get the KeyPressed event.
I did find a workaround by listening to the KeyReleased event though.
kaimast commentedon Oct 12, 2022
For me the problem has been resolved because #1230 was merged.
kaimast commentedon Oct 12, 2022
Seems quite different from this issue. You seem to always want to receive the ESC event independent of whether a text input is focused, or do I misunderstand?
ModProg commentedon Oct 13, 2022
yes, but as the textinput is the only thing present, listening for it loosing focus is also fine.