The future of MirInputEvent

[Alexandros Frantzis]

On Thu, Jun 25, 2015 at 10:45:10AM -0700, Robert Carr wrote:
> Hi!

> I think the value of MirInputEvent is pretty limited.

Having a base MirInputEvent and deriving specialized input event types
seems like a natural model for the domain. However, it's problematic
since the interface shared by the types is small, so the benefits of
inheritance are mostly lost, because most code needs to know the exact
type it's working with.

That being said, input events are usually treated specially as a
group at the higher levels, so it's useful to have a way to check if an
event is an input event. This can be achieved without a base
MirInputEvent type by checking the type manually:

  if (type == mir_event_keyboard || type == mir_event_motion || ...)

However, I think it's worth having a convenience function:

  if (mir_event_is_input_event(event))

> I think it's possible to defend as correct, for example something may
> wish to access the time of events without knowing the event
> type...even then though this seems pretty marginal.

Writing a wrapper to provide this functionality is trivial, although not
elegant from a user's point of view, since users need to explicitly care
about the types.

> On the other hand there is no way to implement the conversion we
> want without casting inm C so I think we'd probably be better to remove it
> in the end...this would also enable us to keep MirEvent as a discriminated
> union...where as it stands thats become awkward with MirInputEvent becoming
> this like...fake type.

Perhaps we could reach a middle ground by trading compile time
type safety for convenience by introducing functions for the common
properties of input events, without having an explicit MirInputEvent
type. The accessor functions would abort if passed an non-input event.

bool mir_event_is_input_event(MirEvent const*)
int64_t mir_input_event_timestamp(MirEvent const*)
MirInputDeviceId mir_input_event_device_id(MirEvent const*)

Thanks,
Alexandros