Is there any particular reason to typedef int64_t to MirInputEventTime here? We're documenting it's nanoseconds-since-the-epoch, and this is not really useful if the type is opaque.
---
467 +typedef int64_t MirTouchInputEventTouchId;
We'll probably not have a full 2^63 touch ids at any point; int32_t maybe? :)
---
479 + /* This touch point was cancelled, an down should have been
480 + received but an up will never come. */
481 + mir_touch_input_event_action_cancel = 3,
Comment seems a bit off, and not just the an/down mismatch :)
Should mention that this is opt-in behaviour, “a down should have been received” is a bit wishy-washy.
“This touch point was cancelled. Any actions taken in response to this touch should be undone. No further events will be delivered for this touch point.
A cancelled event will only be sent to a client that has explicitly enabled cancellation, via mir_input_break_me_harder()”
Maybe?
---
482 + /* This touch point is unchanged but is reported as part of
483 + a full state update. */
484 + mir_touch_input_event_action_none = 4
Why do we have this? Is there an ability to request a full-state update?
---
518 +// Touch is made with a mouse through touch emulation
519 + mir_touch_input_tool_type_mouse = 3,
Hm. Would it be nice for clients if instead of get_touch_id(..., index) and get_*(..., index) we just had.
get_*(MirTouchInputEvent const* event, MirTouchInputEventTouchId id)?
That would seem be a more natural API to me, but we'd need toolkit input as to whether or not that's better.
---
655 + default:
656 + return MirInputEventType();
I'm a fan of abort() when faced with egregious client API abuse. Likewise for the DeviceId just afterwards.
179 +MirInputEvent* mir_event_ get_input_ event(MirEvent* ev);
Const? Why is the MirEvent and MirInputEvent mutable?
---
229 +typedef struct _MirInputEvent MirInputEvent;
344 +typedef struct _MirKeyInputEvent MirKeyInputEvent;
460 +typedef struct _MirTouchInputEvent MirTouchInputEvent;
We've traditionally not used the typedef struct _Foo Foo idiom. Any particular reason to not make this “typedef struct Mir*InputEvent Mir*InputEvent”?
---
271 +MirInputEventTime mir_input_ event_get_ event_time( MirInputEvent const* ev);
Is there any particular reason to typedef int64_t to MirInputEventTime here? We're documenting it's nanoseconds- since-the- epoch, and this is not really useful if the type is opaque.
---
467 +typedef int64_t MirTouchInputEv entTouchId;
We'll probably not have a full 2^63 touch ids at any point; int32_t maybe? :)
---
479 + /* This touch point was cancelled, an down should have been input_event_ action_ cancel = 3,
480 + received but an up will never come. */
481 + mir_touch_
Comment seems a bit off, and not just the an/down mismatch :)
Should mention that this is opt-in behaviour, “a down should have been received” is a bit wishy-washy.
“This touch point was cancelled. Any actions taken in response to this touch should be undone. No further events will be delivered for this touch point.
A cancelled event will only be sent to a client that has explicitly enabled cancellation, via mir_input_ break_me_ harder( )”
Maybe?
---
482 + /* This touch point is unchanged but is reported as part of input_event_ action_ none = 4
483 + a full state update. */
484 + mir_touch_
Why do we have this? Is there an ability to request a full-state update?
---
518 +// Touch is made with a mouse through touch emulation input_tool_ type_mouse = 3,
519 + mir_touch_
Are we going to do this?
---
549 +MirTouchInputE ventTouchAction mir_touch_ input_event_ get_touch_ action( MirTouchInputEv ent const* event, size_t touch_index);
Hm. Would it be nice for clients if instead of get_touch_id(..., index) and get_*(..., index) we just had. nputEvent const* event, MirTouchInputEv entTouchId id)?
get_*(MirTouchI
That would seem be a more natural API to me, but we'd need toolkit input as to whether or not that's better.
---
655 + default: pe();
656 + return MirInputEventTy
I'm a fan of abort() when faced with egregious client API abuse. Likewise for the DeviceId just afterwards.
---
761 +MirTouchInputE ventTouchAction mir_touch_ input_event_ get_touch_ action( MirTouchInputEv ent const* event, size_t touch_index)
Oooh, ugh. Maybe we need an actual MirTouchInputEvent to pass in here, so that we can maintain the state that lets us implement this properly?