Re: Porting QtUbuntu to mirclient - Review needed

2015-01-27 Thread 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

Re: client funcs in libmircommon

2015-01-27 Thread 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. T

Re: More typing

2015-01-27 Thread 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 differe

Re: client funcs in libmircommon

2015-01-27 Thread 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 commo

Re: client funcs in libmircommon

2015-01-27 Thread 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 proble

Re: client funcs in libmircommon

2015-01-27 Thread 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 to

Re: client funcs in libmircommon

2015-01-27 Thread 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 H

The R word

2015-01-27 Thread 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 proposal