More typing

Wed Jan 28 01:46:12 UTC 2015

On Fri, Jan 23, 2015 at 1:01 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> wrote:
> 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.

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.

> 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

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.
> 
> 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()

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.

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