The future of MirInputEvent

[Daniel van Vugt]

+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.


On 26/06/15 01:00, Alan Griffiths wrote:
> Hi All,
>
> In case anyone has missed it there's a debate about future direction
> started on two competing MPs:
>
>
> https://code.launchpad.net/~alan-griffiths/mir/event-timestamps/+merge/262879
> <https://code.launchpad.net/%7Ealan-griffiths/mir/event-timestamps/+merge/262879>
>
> https://code.launchpad.net/~alan-griffiths/mir/event-upcast/+merge/262965 <https://code.launchpad.net/%7Ealan-griffiths/mir/event-upcast/+merge/262965>
>
> it boils down  to whether the MirInputEvent abstraction is actually
> useful in addition to MirKeyboardEvent, MirPointerEvent and MirTouchEvent.
>
> Please decide before the weekend.
>
> Alan
>