The future of MirInputEvent

[Christopher James Halse Rogers]

On Fri, Jun 26, 2015 at 12:09 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> wrote:
> +1 on having a discussion. I wondered the same when I touched those 
> APIs a few months ago.
> 
> I don't think the intermediate InputEvent is useful enough to keep. 
> Conceivably any app/toolkit developer could want to correlate other 
> types of events with input just as much as correlating input with 
> input. So I think the commonality is "Event" and not "InputEvent".
> 
> Mir Event "1.0" did not have any "input event" structure. And X 
> doesn't either:   http://tronche.com/gui/x/xlib/events/structures.html
> So people can very happily use (and have done for years) an API that 
> has no intermediate InputEvent class.

Functionally X does have an intermediate class; the XAnyEvent member of 
that union.


That doesn't invalidate your point, though.

It would be nice to not have to duplicate accessors for common event 
fields. mir_touch_event_timestamp, mir_keyboard_event_timestamp, 
mir_pointer_event_timestamp, mir_touch_event_input_device_id, 
mir_keyboard_event_input_device_id, mir_pointer_event_input_device_id, 
… and so on.

I guess I've argued myself into supporting the 
mir_foo_event_input_event() branch...