Users of this crate may want a one-api-fits-all for Cursor-like devices. Mice and touch can be used for all the same interactions, and in fact Touch digitizers feature many of the same axes as a stylus (pressure, contact size, angle, and multitouch) and mice share some as well (scroll, many buttons, high-res/high-sampling-rate motion).
On the wayland side, these emulations are trivial and I have done cursory research in implementing them. Unsure about the windows side (though that already features Mouse emulation provided by the Ink API itself)
These functions do overlap some with windowing abstractions. If all this info can be queried from common frameworks then there's no need for mirroring those features in this crate and merging other cursors with this crate's output could be left to the user. Research needed!
Users of this crate may want a one-api-fits-all for Cursor-like devices. Mice and touch can be used for all the same interactions, and in fact Touch digitizers feature many of the same axes as a stylus (pressure, contact size, angle, and multitouch) and mice share some as well (scroll, many buttons, high-res/high-sampling-rate motion).
On the wayland side, these emulations are trivial and I have done cursory research in implementing them. Unsure about the windows side (though that already features Mouse emulation provided by the Ink API itself)
These functions do overlap some with windowing abstractions. If all this info can be queried from common frameworks then there's no need for mirroring those features in this crate and merging other cursors with this crate's output could be left to the user. Research needed!