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

How to create instance of WindowEvent::KeyboardInput / KeyEvent #3606

Open
junglie85 opened this issue Mar 25, 2024 · 7 comments
Open

How to create instance of WindowEvent::KeyboardInput / KeyEvent #3606

junglie85 opened this issue Mar 25, 2024 · 7 comments
Labels
S - api Design and usability S - docs Awareness, docs, examples, etc.

Comments

@junglie85
Copy link

I need (want) to created an instance of WindowEvent::KeyboardInput for testing purposes, but I can't because key_event.platform_specific is private to me as a consumer.

#3176 does not provide a solution.

How can I create an instance of this event?

@kchibisov
Copy link
Member

I thought that it's a duplicate, but there's clear no issue about this. We'll likely need an API change. Probably Default impl or cfg(test) impl will work.

You can also construct specific bits, like logical/physical key, which should be more or less sufficient for testing.

@kchibisov kchibisov added C - nominated Nominated for discussion in the next meeting S - api Design and usability labels Mar 25, 2024
@junglie85
Copy link
Author

I think either of those options would work. I was also wondering if the field value could be an option.

Agreed, I can get quite a lot of mileage from the components, but it would be nice to be able to pass the whole event to a handler method.

I assume any API changes now would be released with the trait API, or later?

@junglie85
Copy link
Author

Similarly, for Modifiers, it's not possible for me to create unit tests where my function received a Modifiers from the event because I cannot instantiate the object with which left/right modifiers are pressed or unknown. I can use ModifiersState.into() to create an instance of Modifiers, but that's about it. It would be helpful to expose a way to create a "real" instance of this object for testing purposes.

I suppose this holds for all of the data structures that can be received in events.

There are of course other approaches, such as creating my own object and taking the necessary values from Modifiers but it would be nice to avoid this extra layer of indirection.

@kchibisov
Copy link
Member

I can use ModifiersState.into() to create an instance of Modifiers, but that's about it. It would be helpful to expose a way to create a "real" instance of this object for testing purposes.

into is a real instance, you can also use Default. The Right/Light is platform specific and shouldn't be relied upon unless you really know what you're doing and why you're doing that. The type that it's Undefined should also suggest that.

@junglie85
Copy link
Author

Does that mean the physical/logical key + location should be used for modifiers instead? If that's the case, when should Modifiers be used?

@kchibisov
Copy link
Member

If you want to detect a particular button press, use logical_key, if you want to detect general state change for bindings, use the Modifiers event.

Modifiers could be changed without any button press at all.

@kchibisov kchibisov added the S - docs Awareness, docs, examples, etc. label Mar 26, 2024
@kchibisov
Copy link
Member

We've discussed it a bit with @madsmtm and I think the current way forward would be to try to make the KeyEventExtra parts pub or provide a way to build it without the extra.

The issue with making it pub is that the trait is not present for all backends and some backends have this type empty, so it could make tests a bit harder to write(will require cfg), but given that the cfg stuff is already present in the user code if they use extra it's likely fine.

@kchibisov kchibisov removed the C - nominated Nominated for discussion in the next meeting label Mar 29, 2024
@kchibisov kchibisov added this to the Version 0.30.0 milestone Mar 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S - api Design and usability S - docs Awareness, docs, examples, etc.
Development

No branches or pull requests

2 participants