sdl/include at main - sdl

You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

History

Sam Lantinga f37eef948c Removed raw mouse events It's too close the 3.2.0 release for an API change like this. If/when we re-add these, some things for consideration: * What use cases does this enable that aren't currently possible? * What cross-platform API guarantees do we make about the availability of these events? e.g. do we try to simulate them where raw input isn't actually available? * How is this different from the existing relative mode, and how do we clearly explain when you want these events vs wanting relative mode? Notes from @expikr: First observation: the reason I originally passed denominators instead of multipliers was because some rational values cannot be exactly represented by floats (e.g 1/120) so instead let the end-developer decide how to do the dividing themselves. It was the reason why it was using split values with an integer numerator to begin with, instead of having both as floats or even just normalize it in advance. On the other hand, passing them as multipliers might have hypothetical uses for dynamically passing end-user controlled scaling in a transparent manner without coupling? (Though in that case why not just do that as additional fields appended to `motion` structs in an API-compatible layout?) So it’s somewhat of a philosophical judgement of what this API of optional availability do we intend for it to present itself as: - should it be a bit-perfect escape hatch with the absolute minimally-denominal abstraction over platform details just enough to be able to serve the full information (á la HIDPIAPI), - or a renewed ergonomic API for splitting relative motion from cursor motion (in light of The Great Warping Purge) so that it is unburdened by legacy RelativeMode state machines, in which case it would be more appropriate to just call it `RELATIVE` instead of `RAW` and should be added alongside another new event purely for cursor events? This alternate API stream was conceived in the context of preserving compatibility of the existing RelativeMode state machine by adding an escape hatch. So given the same context, my taste leans towards the former designation. However, as The Great Warping Purge has made it potentially viable to do so, if I were allowed to break ABI by nuking the RelativeMode state machine entirely, I would prefer the latter designation unified as one of three separate components split from the old state machine, each independently controlled by platform-dependent availability without any state switching of a leaky melting pot: - cursor visibility controls (if platform has cursor) - cursor motion events (if platform has cursor) - relative motion events (if the platform reports hardware motion)	5 hours ago
..
SDL3	Removed raw mouse events	5 hours ago
build_config	ngage: Remove Nokia N-Gage support.	1 week ago

Sam Lantinga f37eef948c Removed raw mouse events

It's too close the 3.2.0 release for an API change like this.

If/when we re-add these, some things for consideration:
* What use cases does this enable that aren't currently possible?
* What cross-platform API guarantees do we make about the availability of these events? e.g. do we try to simulate them where raw input isn't actually available?
* How is this different from the existing relative mode, and how do we clearly explain when you want these events vs wanting relative mode?

Notes from @expikr:
First observation: the reason I originally passed denominators instead of multipliers was because some rational values cannot be exactly represented by floats (e.g 1/120) so instead let the end-developer decide how to do the dividing themselves. It was the reason why it was using split values with an integer numerator to begin with, instead of having both as floats or even just normalize it in advance.

On the other hand, passing them as multipliers might have hypothetical uses for dynamically passing end-user controlled scaling in a transparent manner without coupling? (Though in that case why not just do that as additional fields appended to `motion` structs in an API-compatible layout?)

So it’s somewhat of a philosophical judgement of what this API of optional availability do we intend for it to present itself as:
- should it be a bit-perfect escape hatch with the absolute minimally-denominal abstraction over platform details just enough to be able to serve the full information (á la HIDPIAPI),
- or a renewed ergonomic API for splitting relative motion from cursor motion (in light of The Great Warping Purge) so that it is unburdened by legacy RelativeMode state machines, in which case it would be more appropriate to just call it `RELATIVE` instead of `RAW` and should be added alongside another new event purely for cursor events?

This alternate API stream was conceived in the context of preserving compatibility of the existing RelativeMode state machine by adding an escape hatch. So given the same context, my taste leans towards the former designation.

However, as The Great Warping Purge has made it potentially viable to do so, if I were allowed to break ABI by nuking the RelativeMode state machine entirely, I would prefer the latter designation unified as one of three separate components split from the old state machine, each independently controlled by platform-dependent availability without any state switching of a leaky melting pot:
- cursor visibility controls (if platform has cursor)
- cursor motion events (if platform has cursor)
- relative motion events (if the platform reports hardware motion)

SDL3

Removed raw mouse events

build_config

ngage: Remove Nokia N-Gage support.