Subject: The future of MirInputEvent

From: Alan Griffiths <[email-masked]>
Date: Thu, 25 Jun 2015 18:00:44 +0100

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

---

From: Robert Carr <[email-masked]>
Date: Thu, 25 Jun 2015 10:45:10 -0700

Hi!

I think the value of MirInputEvent is pretty limited. 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. 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.

Thanks,
Robert

On Thu, Jun 25, 2015 at 10:00 AM, Alan Griffiths <
[email-masked]> wrote:

> <
> 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
> >
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 26 Jun 2015 10:09:56 +0800

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

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Fri, 26 Jun 2015 12:55:21 +1000

On Fri, Jun 26, 2015 at 12:09 PM, Daniel van Vugt 
<[email-masked]> wrote:
> +1 on having a discussion. I wondered the same when I touched those 
> APIs a few months ago.
> 
> 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...

---

From: Alexandros Frantzis <[email-masked]>
Date: Fri, 26 Jun 2015 11:01:44 +0300

> 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

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

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 26 Jun 2015 16:12:23 +0800

Rather than querying types and aborting you can simplify things for 
clients by just returning NULL instead:

if (MirTouchEvent* touch = mir_event_as_touch_event(event))
{
     ...
}

Segfaulting in dereferencing NULL is just as reliable as aborting, but 
this way requires less effort to use the client API.