Subject: More typing

From: Daniel van Vugt <[email-masked]>
Date: Thu, 22 Jan 2015 16:23:26 +0800

Looking at an example of changing from the old input event API to the 
new one in Mir 0.10:

http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2246?compare_revid=2128#examples/fingerpaint.c

You can see it requires a lot more code now.

I'm wondering if anyone has any thoughts on how we might make things 
simpler for users again before this becomes the norm...?

- Daniel

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 22 Jan 2015 16:35:37 +0800

Initial thoughts:

"InputEvent/input_event" is mentioned too much. So:

     MirInputEvent* input = mir_event_get_input_event(event);
     MirTouchInputEvent* touch =
         mir_input_event_get_touch_input_event(input);
     x = mir_touch_input_event_get_touch_axis_value(
             touch, 0, mir_touch_input_axis_x);

could be easily renamed to something like:

     MirInput* input = mir_event_get_input(event);
     MirTouch* touch = mir_input_get_touch(input);
     x = mir_touch_get_axis(touch, 0, mir_touch_axis_x);

I'm not sure if we really need MirInput(Event) in there either. So it 
could be simpler again:

     MirTouch* touch = mir_event_get_touch(event);
     x = mir_touch_get_axis(touch, 0, mir_touch_axis_x);

- Daniel

---

From: Daniel d'Andrada <[email-masked]>
Date: Thu, 22 Jan 2015 08:08:27 -0200

> simpler for users again before this becomes the norm...?

Having a quick look, the cause seems to be because android merged touch
and mouse input under the same event structure (motion events). For
things like dragging and clicking/tapping (which comprises most of the
interactions you do) this is a blessing as you handle both in the same
way. So you don't have to bother telling them apart unless you want to
do something mouse or touch specific.

But having touch and mouse in completely separate APIs you end up
duplicating code.

---

From: Robert Carr <[email-masked]>
Date: Thu, 22 Jan 2015 10:53:05 -0800

Hi Daniel, Daniel! (:p)

First w.r.t duflus concerns:

I guess I tend to shy away from these sort of abbreviated API's as a habit
I picked up from the GLib programming days.

My concern is that once you choose abbreviations you have to remember which
abbreviation you chose, on the other hand if the
function is always of canonical forms:

NamespaceClassFoo namespace_class_get_foo(NamespaceClass instance, size_t
foo_index)

etc

You have a fair amount of repeating yourself but each type name is easy to
guess...I guess to me this is a pretty significant advantage and im
inclined to keep it. Interested in more feedback I guess.
On Thu, Jan 22, 2015 at 12:35 AM, Daniel van Vugt <
[email-masked]> wrote:

>> http://bazaar.launchpad.net/~mir-team/mir/development-
>> branch/revision/2246?compare_revid=2128#examples/fingerpaint.c
>>
>>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>

---

From: Robert Carr <[email-masked]>
Date: Thu, 22 Jan 2015 11:03:09 -0800

Hi dandrader! It seems to me like you have a different series of concerns
than duflu and are concerned about the semantics of the API rather than the
number of characters in the method names.

It's unfortunate that this split is necessary as the current model does
work so well for clicking/tapping. The current model can be kind of
difficult in regards to pointers though in at least a few areas:

1. Pointer/touch actions, e.g. the weird masking stuff...I think the new
model is obviously more clear here
2. Interpretation of hover events "Cursor motion or touchpad hover or
stylus?"
3. Interpretation of strange touch devices, e.g. how do you avoid treating
a button press on a stylus as a click from the system cursor

I hope that doing the pointer/touch event split will solve these issues in
the client library rather than require down-streams to correctly do so.

It perhaps does involve some more typing for downstreams (though a correct
implementation of the above points with current API would require some more
typing too), but I think this is offset
by the fact that its hard to get things wrong.

Thanks,
Robert

On Thu, Jan 22, 2015 at 2:08 AM, Daniel d'Andrada <
[email-masked]> wrote:

> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 23 Jan 2015 10:01:51 +0800

dandrada:

Yeah the separation of touch from mouse events doubles the number of 
functions, but that's probably useful in the long run. Only dumb legacy 
apps want to treat them as the same thing. Any modern app will see them 
as different (e.g. drag with a finger scrolls, but not with the mouse).

racarr:

My personal preference for clarifying this is to ensure each "class" 
name is usually a single noun where possible. Hence:
    mir_input_event_get_touch_input_event
    mir_input_get_touch

Where not possible, you could consider dropping underscores in places:
    mir_input_event_get_touch_input_event
    mir_inputevent_gettouchinputevent
Although we've never done that, and in the wider world seems uncommon.

As a compromise, I suggest that we can at least change:
    MirTouchInputEvent -> MirTouchEvent
    _touch_input_event -> _touch_event

I would like to go further (and the opacity of the API actually supports 
this more than the old API):
    MirTouchInputEvent -> MirTouch
    _touch_input_event -> _touch

Because everything's opaque, there's no need to mention that the touch 
is an "Event" once you have a pointer to it. The conversions are one-way 
so we don't need to advertise any kind of inheritance from *Event once 
we have a MirTouch.

This shortest form only creates a design problem for:
    MirPointerInputEvent -> ? (MirMotion?)

If "pointer" events always represent a synthesised "cooked" event 
originating from something that could be (usually) a relative input 
device, then maybe it too could be used to represent a touch and solve 
dandrada's issue:   mir_touch_event_to_pointer_event()

On 23/01/15 02:53, Robert Carr wrote:
> I guess I tend to shy away from these sort of abbreviated API's as a
> habit I picked up from the GLib programming days.
>
> My concern is that once you choose abbreviations you have to remember
> which abbreviation you chose, on the other hand if the
> NamespaceClassFoo namespace_class_get_foo(NamespaceClass instance,
> size_t foo_index)
>
> etc
>
> You have a fair amount of repeating yourself but each type name is easy
> to guess...I guess to me this is a pretty significant advantage and im
> On Thu, Jan 22, 2015 at 12:35 AM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Initial thoughts:
>
>          MirInputEvent* input = mir_event_get_input_event(__event);
>              mir_input_event_get_touch___input_event(input);
>          x = mir_touch_input_event_get___touch_axis_value(
>     I'm not sure if we really need MirInput(Event) in there either. So
>     it could be simpler again:
>
>         http://bazaar.launchpad.net/~__mir-team/mir/development-__branch/revision/2246?compare___revid=2128#examples/__fingerpaint.c
>         <http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2246?compare_revid=2128#examples/fingerpaint.c>
>
>
>     [email-masked] <mailto:[email-masked]>
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Wed, 28 Jan 2015 12:46:12 +1100

On Fri, Jan 23, 2015 at 1:01 PM, Daniel van Vugt 
<[email-masked]> wrote:
> functions, but that's probably useful in the long run. Only dumb 
> legacy apps want to treat them as the same thing. Any modern app will 
> see them as different (e.g. drag with a finger scrolls, but not with 
> the mouse).
> 
> racarr:
> 

I... have no idea why you would ever want to do that. The primary 
reason for shorter names is readability; why would you destroy the 
readability of a name to make it shorter?

If you're concerned about typing, you should invest some time in your 
environment; every editor you could possibly want to use will have some 
sort of autocomplete available.

> I would like to go further (and the opacity of the API actually 
> supports this more than the old API):

This particular case is somewhat confused in the current naming. There 
are two different meanings of “touch” used. One is the 
MirTouchInputEvent, which contains events for multiple touches (up, 
down, axis changes).

I suspect this could be better named.

> 
> Because everything's opaque, there's no need to mention that the 
> touch is an "Event" once you have a pointer to it. The conversions 
> are one-way so we don't need to advertise any kind of inheritance 
> from *Event once we have a MirTouch.
> 
> device, then maybe it too could be used to represent a touch and 
> solve dandrada's issue:   mir_touch_event_to_pointer_event()

The synthesis happens server-side. That's where you know (for example) 
whether 2-finger scrolling is enabled, and whether it's natural or 
inverted (or whatever).

mir_touch_event_to_pointer_event() doesn't make sense; you could only 
use this if mice generated touch events, and in that case “touch 
event" is meaningless.

>>         Looking at an example of changing from the old input event 
>> API
>>         to the
>>         new one in Mir 0.10:
>> 
>>