Open szbergeron opened 4 years ago
CC @glennsl for design approach (continuation of discussion in https://github.com/revery-ui/revery/pull/766)
CC @Et7f3 for any C89 dumbness I've overlooked
CI failure expected, need to fix the waylandevents usage of PanEvent
Not entirely sure what I'm looking at, since it seems like there's even syntax errors in SDL_events.h
with the SDL_Pan
struct being unterminated. I think I get the gist of it though.
I don't understand why the source is a separate pan type. I thought that was a field common to every type of event. And if it is, it looks like axis
is common across all of them as well.
Forgot to commit some more recent stuff, syntax errors should at least be fixed lol.
The source isn't actually possible to provide in the same event for wayland, since it's split out into its own event. If events are assumed to use the source from any prior events this should work. It might make sense to special case wayland for this and store the current source into a static var and plug that into any events that are dispatched.
Oh, that's weird. But that assumption has to be made somewhere, right? Might as well make it as early as possible.
@glennsl should be slightly better now
@glennsl @Et7f3 any thoughts? Am hoping to jump on the libscroll integration stuff if this is good to go
/azp run
Those mojave checks didn't rerun, and were last run in april. Is something going on with CI?
mojave was a bad name of 10.13 and not supported anymore in azure.
Refactor pan events as the "kitchen sink" approach to representing events really doesn't generalize well to less verbose reprs (wayland, cocoa), while a more slimmed repr can generalize fairly well to more verbose reprs (windows)