Skip to content
\n

I tried to update this part of code and got the following result:

\n
                        example.update(winit::event::WindowEvent::KeyboardInput {\n                            event: KeyEvent {\n                                physical_key: PhysicalKey::Code(KeyCode::Space),\n                                state: ElementState::Pressed,\n                                logical_key: Key::Named(NamedKey::Space),\n                                text: None,\n                                location: KeyLocation::Standard,\n                                repeat: false,\n                                platform_specific: false,\n                            },\n                            device_id: unsafe { winit::event::DeviceId::dummy() },\n                            is_synthetic: false,\n                        });
\n

However, I've got a problem with platdform_specific: false here, since it's a private attribute and I couldn't find a new constructor or something like that for it. May I ask what's the proper way to fix this with the latest winit update?

","upvoteCount":1,"answerCount":1,"acceptedAnswer":{"@type":"Answer","text":"

This is so cursed...

\n

Why not just use a logical_key? Maybe some other state you actually need instead of doing synthetic event like that.

\n

I could think of creating such events for testing purposes, and hide the platform_specific field for tests, but not sure what to do with general code, since platform specific fields sometimes are required...

\n

I'd just suggest to not do what you're doing in this example, since there's clearly some abuse going on.

","upvoteCount":1,"url":"https://github.com/rust-windowing/winit/discussions/3176#discussioncomment-7363114"}}}

Create instance of WindowEvent::KeyboardInput. #3176

Answered by kchibisov
TornaxO7 asked this question in Q&A
Discussion options

You must be logged in to vote

This is so cursed...

Why not just use a logical_key? Maybe some other state you actually need instead of doing synthetic event like that.

I could think of creating such events for testing purposes, and hide the platform_specific field for tests, but not sure what to do with general code, since platform specific fields sometimes are required...

I'd just suggest to not do what you're doing in this example, since there's clearly some abuse going on.

Replies: 1 comment 1 reply

Comment options

You must be logged in to vote
1 reply
@TornaxO7
Comment options

Answer selected by TornaxO7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet
2 participants