More typing

[Daniel van Vugt]

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:
> 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
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> wrote:
>
>     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
>
>
>     On 22/01/15 16:23, Daniel van Vugt wrote:
>
>         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
>         <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
>
>
>     --
>     Mir-devel mailing list
>     Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>