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

Add max click timings & distance to Options #4986

Closed
wants to merge 1 commit into from

Conversation

Azorlogh
Copy link

  • I have followed the instructions in the PR template

Moves the click timing & distance constants to the Options struct so they can be configured by users.

Note: This need came up as part of my investigation of mvlabat/bevy_egui#302. Essentially, on some platforms we are not guaranteed to have correct timekeeping so it's useful to be able to disable the max click duration in this case.

.interactions
.entry(self.memory.viewport_id)
.or_default(),
&self.memory.options,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't super pretty, but otherwise it conflicts with the mut access of memory above

Copy link
Owner

@emilk emilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, but we need to fix that deadlock

@@ -2721,7 +2721,7 @@ fn register_rect(ui: &Ui, rect: Rect) {
return;
}

let is_clicking = ui.input(|i| i.pointer.could_any_button_be_click());
let is_clicking = ui.memory(|m| ui.input(|i| i.pointer.could_any_button_be_click(&m.options)));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This deadlocks (try holding down all modifier keys in the demo app)

@emilk
Copy link
Owner

emilk commented Aug 26, 2024

There is an alternative PR for this in #4942 which I think uses a slightly better approach, and avoids the deadlock

@Azorlogh
Copy link
Author

There is an alternative PR for this in #4942 which I think uses a slightly better approach, and avoids the deadlock

Oh I totally missed it! Yeah I agree that other one is a lot cleaner 👌 I'll close this one

@Azorlogh Azorlogh closed this Aug 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants