Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it possible for TextInput to emit a message when gaining/losing foccus. #819

Open
thenlevy opened this issue Apr 8, 2021 · 7 comments
Labels
feature New feature or request shell widget

Comments

@thenlevy
Copy link
Contributor

thenlevy commented Apr 8, 2021

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.

@hecrj
Copy link
Member

hecrj commented 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 Event was captured by iced, you can always use UserInterface::update directly which returns a list of event::Status.

@hecrj hecrj added the question Further information is requested label May 4, 2021
@kaimast
Copy link
Contributor

kaimast commented May 6, 2021

How about a widget that that behaves like Container but allows to handle events that are not processed by its children?

Using UserInterface::update works but seems to require re-implementing some of the functionality of program::State.

@kaimast
Copy link
Contributor

kaimast commented 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 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.

(Please correct me, if I am wrong)

@hecrj hecrj added feature New feature or request shell widget and removed question Further information is requested labels Jan 20, 2022
@ModProg
Copy link

ModProg commented 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
Copy link
Contributor

kaimast commented Oct 12, 2022

For me the problem has been resolved because #1230 was merged.

@kaimast
Copy link
Contributor

kaimast commented 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.

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
Copy link

ModProg commented Oct 13, 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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request shell widget
Projects
None yet
Development

No branches or pull requests

4 participants