Re: Porting QtUbuntu to mirclient - Review needed

[Cemil Azizoglu]

I meant 0.11 :-).

On Mon, Jan 26, 2015 at 2:38 PM, Cemil Azizoglu <
cemil.azizo...@canonical.com> wrote:

> FYI, we plan to land these MPs, along with mir 0.12 (expected to happen,
> later this week or early next week).
>
> -C
>
> On Mon, Jan 26, 2015 at 2:16 PM, Robert Carr 
> wrote:
>
>> Hi team!
>>
>> I need some help preparing the port of QtUbuntu to MirClient to land with
>> the next set of silos.
>>
>> I'll need review on this branch:
>>
>> https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164
>>
>> the dependent branch is here:
>>
>> https://code.launchpad.net/~mir-team/platform-api/expose-mir-connection/+merge/245054
>>
>> Thanks!
>>
>> --
>> Mir-devel mailing list
>> Mir-devel@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>>
>>
>
>
> --
> Cemil Azizoglu
> Mir Display Server - Team Lead
> Canonical USA
>



-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA
-- 
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: client funcs in libmircommon

[Christopher James Halse Rogers]

On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt 
 wrote:

We seem to have some client functions residing in libmircommon now...

That sounds reasonable at first but doesn't this prevent us from 
being able to bump the common ABI without breaking clients?


No? They'll just link to libmirclient8. The old libmirclient8 will link 
to libmircommon3 and the new libmirclient8 will link to libmircommon4, 
and everything will work as expected.



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: More typing

[Christopher James Halse Rogers]

On Fri, Jan 23, 2015 at 1:01 PM, Daniel van Vugt 
 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
>

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





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@lists.ubuntu.com 
Modify settings 

Re: client funcs in libmircommon

[Daniel van Vugt]

I forgot (and aren't totally sure) about indirect dependencies.

Although these client functions are obviously versioned, so even the 
indirect dependencies will point to funcname@@MIR_COMMON_3.x which 
sounds like it could become a problem for clients/toolkits rather 
quickly as we bump the common ABI.



On 28/01/15 08:57, Christopher James Halse Rogers wrote:

On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
 wrote:

We seem to have some client functions residing in libmircommon now...

That sounds reasonable at first but doesn't this prevent us from being
able to bump the common ABI without breaking clients?


No? They'll just link to libmirclient8. The old libmirclient8 will link
to libmircommon3 and the new libmirclient8 will link to libmircommon4,
and everything will work as expected.



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: client funcs in libmircommon

[Christopher James Halse Rogers]

On Wed, Jan 28, 2015 at 12:49 PM, Daniel van Vugt 
 wrote:

I forgot (and aren't totally sure) about indirect dependencies.

Although these client functions are obviously versioned, so even the 
indirect dependencies will point to funcname@@MIR_COMMON_3.x which 
sounds like it could become a problem for clients/toolkits rather 
quickly as we bump the common ABI.


Just to be clear, we're not exporting anything that a client would be 
expected to directly call from libmircommon, right? The callstack might 
go client code→libmirclient→libmircommon, but never client 
code→libmircommon, right?


In which case the client code never references anything in 
libmircommon, it's symbol table contains nothing from libmircommon, and 
everything is handled by ld.so when libmirclient is loaded.





On 28/01/15 08:57, Christopher James Halse Rogers wrote:

On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
 wrote:
We seem to have some client functions residing in libmircommon 
now...


That sounds reasonable at first but doesn't this prevent us from 
being

able to bump the common ABI without breaking clients?


No? They'll just link to libmirclient8. The old libmirclient8 will 
link
to libmircommon3 and the new libmirclient8 will link to 
libmircommon4,

and everything will work as expected.



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: client funcs in libmircommon

[Daniel van Vugt]

That's the point. Yes, we do now have a handful of client functions 
exported from libmircommon directly to (future) clients. So that's why I 
raised it...



On 28/01/15 09:55, Christopher James Halse Rogers wrote:

On Wed, Jan 28, 2015 at 12:49 PM, Daniel van Vugt
 wrote:

I forgot (and aren't totally sure) about indirect dependencies.

Although these client functions are obviously versioned, so even the
indirect dependencies will point to funcname@@MIR_COMMON_3.x which
sounds like it could become a problem for clients/toolkits rather
quickly as we bump the common ABI.


Just to be clear, we're not exporting anything that a client would be
expected to directly call from libmircommon, right? The callstack might
go client code→libmirclient→libmircommon, but never client
code→libmircommon, right?

In which case the client code never references anything in libmircommon,
it's symbol table contains nothing from libmircommon, and everything is
handled by ld.so when libmirclient is loaded.




On 28/01/15 08:57, Christopher James Halse Rogers wrote:

On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
 wrote:

We seem to have some client functions residing in libmircommon now...

That sounds reasonable at first but doesn't this prevent us from being
able to bump the common ABI without breaking clients?


No? They'll just link to libmirclient8. The old libmirclient8 will link
to libmircommon3 and the new libmirclient8 will link to libmircommon4,
and everything will work as expected.




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: client funcs in libmircommon

[Christopher James Halse Rogers]

Ah, ok. That would seem to be incorrect.

On Wed, Jan 28, 2015 at 12:58 PM, Daniel van Vugt 
 wrote:
That's the point. Yes, we do now have a handful of client functions 
exported from libmircommon directly to (future) clients. So that's 
why I raised it...



On 28/01/15 09:55, Christopher James Halse Rogers wrote:

On Wed, Jan 28, 2015 at 12:49 PM, Daniel van Vugt
 wrote:

I forgot (and aren't totally sure) about indirect dependencies.

Although these client functions are obviously versioned, so even the
indirect dependencies will point to funcname@@MIR_COMMON_3.x which
sounds like it could become a problem for clients/toolkits rather
quickly as we bump the common ABI.


Just to be clear, we're not exporting anything that a client would be
expected to directly call from libmircommon, right? The callstack 
might

go client code→libmirclient→libmircommon, but never client
code→libmircommon, right?

In which case the client code never references anything in 
libmircommon,
it's symbol table contains nothing from libmircommon, and everything 
is

handled by ld.so when libmirclient is loaded.




On 28/01/15 08:57, Christopher James Halse Rogers wrote:

On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
 wrote:
We seem to have some client functions residing in libmircommon 
now...


That sounds reasonable at first but doesn't this prevent us from 
being

able to bump the common ABI without breaking clients?


No? They'll just link to libmirclient8. The old libmirclient8 will 
link
to libmircommon3 and the new libmirclient8 will link to 
libmircommon4,

and everything will work as expected.



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

The R word

[Daniel van Vugt]

All,

Just a heads up... we're still seeing more regressions occurring than we 
really should.


Although we can't expect authors to predict how other authors might 
modify their code into the future [1], I think the common factors we can 
improve on are:


 * More manual testing of merge proposals - would have found many of 
the regressions we're seeing before they landed.


 * Smaller merge proposals - allows for higher quality, more carefully 
considered code reviews.


- Daniel


[1] Someone once said "It's impossible to make anything foolproof, 
because fools are so ingenious."


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel