[00:06] <racarr_> kgunn: Ok will at least write up some sort of study on it by tomorrow
[00:07] <racarr_> RAOF: Ping?
[00:08] <racarr_>  / anyone else who has thought about client cursor APIss
[00:08] <racarr_> I think it might be time
[00:08] <racarr_> xmir doesnt want the cursor
[00:08] <racarr_> nested unity8 does
[00:08] <racarr_> rather than add another hack to USC XMir should request to turn off the cursor I think
[00:38] <greyback> kgunn: just tried reproducing bug 1289058 now, but I can't even get the signon UI to appear
[01:39] <RAOF> racarr_: Pong.
[01:41] <RAOF> racarr_: I think that both XMir and Unity8 want usc to handle the cursor at some points, and to handle the cursor themselves at other points.
[01:41] <RAOF> (Although U8 will likely want to handle the cursor more often than XMir)
[01:42] <RAOF> racarr_: I've suggested to greyback that U8 just turn off the cursor and handle it themselves, to unblock things.
[02:03] <racarr_> RAOF: MM its not to hard to unblock things...I was just thinking maybe its a nice excuse to add client cursor API
[02:03] <racarr_> and figured if anyone had an opinion on how that should look it would probably be you
[02:04] <RAOF> Ah, if you've got time to do a client cursor API then that'd be aces.
[02:05] <racarr_> I mean its pretty simple right, MirCursor *c = mir_upload_cursor_sync(connection, pixels); mir_surface_set_cursor(surface, pointerid(?), cursor)
[02:05] <racarr_> well we dont hae multiple cursors right now so ignore that lol
[02:05] <racarr_> just surface, cursor
[02:05] <racarr_> and there is not much more to it
[02:05] <racarr_> I think?
[02:06] <RAOF> Roughly?
[02:07] <RAOF> The other option is to only expose symbolic pointer names in the API.
[02:07] <RAOF> Which I think would be better?
[02:09] <duflu> racarr_: Don't forget the hotspot x/y parameters with each image :)
[02:10] <RAOF> Right :)
[02:10] <duflu> https://bugs.launchpad.net/mir/+bug/1206780
[02:10] <duflu> https://bugs.launchpad.net/mir/+bug/1189775
[02:20] <RAOF> racarr_: So, I think the API should probably look something like... mir_cursor_set_cursor(MirSurface* surface, char const* cursor_name); mir_cursor_load_theme(char const* theme_name);
[02:23] <RAOF> racarr_: Hm, or something similar.
[02:27] <RAOF> racarr_: Actually, maybe a first go could be MirCursor c = mir_upload_cursor(connection, buffer_containing_xcursor_data); mir_surface_set_cursor(surface, cursor);
[02:27] <RAOF> racarr_: And copy http://cgit.freedesktop.org/wayland/wayland/tree/cursor/xcursor.c again :)
[03:47] <racarr_> RAOF: duflu: Aha sorry my IRC client hung
[03:48] <racarr_> symbolic names mebbe...Im not sure
[03:48] <racarr_> I feel like some clients will reasonably want to upload custom cursors
[03:48] <racarr_> GIMP, etc
[03:48] <racarr_> im not sure
[03:48] <racarr_> so maybe thats better done at the toolkit level
[03:48] <racarr_> maybe we should support both
[03:48] <racarr_> I dunno
[03:50] <RAOF> racarr_: Yeah.
[03:50] <RAOF> racarr_: Did you get all my comments?
[03:50] <RAOF> Particularly: racarr_: Actually, maybe a first go could be MirCursor c = mir_upload_cursor(connection, buffer_containing_xcursor_data); mir_surface_set_cursor(surface, cursor);
[03:50] <RAOF> ... racarr_: And copy http://cgit.freedesktop.org/wayland/wayland/tree/cursor/xcursor.c again :)
[03:51] <racarr_> RAOF: Yes I did
[03:51] <racarr_> yeah I think that is going to be
[03:51] <racarr_> the first go
[03:52] <RAOF> The next cut being MirCursorTheme t = mir_cursor_theme_from_$X(connection, <filename, symbolic theme name, buffer>); MirCursor c = mir_cursor_from_theme(t, char const* symbolic_name);
[08:28] <alf__> rsalveti: @glmark2, sure, I will prepare a package update branch and contact you for further guidance
[11:37] <kgunn> anpok: so i saw AlbertA's post in the bug...so do we think there's a combination of MP's that will allow mir0.1.6 to get promoted ? (...while we may have to hold back some of our bug fix?)
[11:42] <kgunn> greyback:  based on https://bugs.launchpad.net/mir/+bug/1289058/comments/8
[11:43] <kgunn> sounds like we need a update to the namespace patch seperate from the fix for 1240400.
[11:43] <greyback> kgunn: I'm rebuilding as I type. Sadly the PPA disappeared
[11:43] <kgunn> greyback: actually https://drive.google.com/a/canonical.com/?tab=wo#folders/0B4GvOYxwuvpFdm5DbXNYUzFDdG8
[11:43] <kgunn> i saved it off
[11:43] <greyback> oh yay
[11:44] <kgunn> sorry..i should have mailed that last night..but i was getting weird
[11:47] <kgunn> greyback: i don't want to suck you into this...so if you just want to redo your branch...anpok or i can test
[11:48] <kgunn> we might even get a silo back up soon
[11:48] <kgunn> ooo...maybe soon is optimistic, we're in line behind the qt landing :P
[11:48] <greyback> yeah I noticed that
[12:08] <kgunn> reboot
[12:22] <anpok> kgunn: i tried to reproduce the issue without mir 1.6 this morning .. and could not
[13:09] <kgunn> anpok: thanks...when you tested 0.1.6, what did you test it with in terms of the unity-mir configuration ?? (or usc for that matter?)
[13:10] <kgunn> ...and when you say mir0.1.6 do you mean lp:~mir-team/mir/trunk-0.1.6 ?
[13:10] <kgunn> ...avoiding the confusion that maybe you tested mir-devel tip :)
[13:14] <anpok> no not yet with 0.1.6
[13:36] <anpok> i couldnt imagine that it could relate to mir changes so I thought to reproduce it with my current setup..
[13:36] <anpok> my wifi was flaky ..
[13:37] <anpok> kgunn: do you already have a reduced branch that only resolves the MirSurface colision in unity-mir?
[13:38] <greyback> anpok: almost done
[13:43]  * greyback loves when a C++ error message contains more lines than his scrollback buffer
[13:51] <greyback> anpok: lp:~gerboland/unity-mir/namespace-to-prevent-collision2
[13:57] <kgunn> dandrader: "maybe" is the answer to your ques from the other channel
[13:57] <kgunn> i think greyback's branch ^^ might do the trick
[14:01] <dandrader> kgunn, ok, let me know if I should jump on it
[14:03] <greyback> kgunn: that's not fixing the bug, but it means we could land the few branches needed to unblock mir0.1.6 anyway
[14:05] <kgunn> greyback: @"not fixing bug"...which bug :) ?
[14:05] <kgunn> the osk one ?
[14:06] <greyback> kgunn: https://bugs.launchpad.net/mir/+bug/1289058 yeah
[14:07] <kgunn> greyback: oh i see...trying to reduce the outstanding MP's down to just the lp:~kgunn72/unity-mir/um-mir-0.1.6
[14:07] <kgunn> +1
[14:07] <greyback> kgunn: right. Thought it best to shrink the landing queue to unblock mir
[14:08] <kgunn> dandrader: yeah...so if you would take a look today at 1289058 that'd be great...
[14:09] <kgunn> greyback: quick one...so you've basically now tests AlbertA's post and proved it wrong ?
[14:09] <kgunn> meaning...removing the bug fix for 1240400 didn't help
[14:10] <greyback> kgunn: http://studio.sketchpad.cc/f2Lr8RTY8z is list I'm proposing for landing. I'm just building now to check everything is ok.
[14:12] <kgunn> greyback: +1....i actually had the same list/idea last night....but it got late...and now we gotta wait :)
[14:13] <kgunn> anpok: greyback dandrader...i gotta step out for some banking...bbiab
[14:15]  * greyback also has to step out a bit, back in 10
[14:18] <anpok> greyback: ok
[14:31] <rsalveti> alf__: thanks
[14:41] <anpok> is it really done that way that osk forwards all input of the side or main stage application?
[14:41] <anpok> i mean motion input at the upper half of the surface
[14:42] <anpok> have to go and get some stuff.. will be back later
[14:46] <greyback> anpok: yeah
[14:48] <greyback> it is a full screen surface, to support all the orientations necessary. Therefore its surface has transparent parts, and shell tries to position an InputArea over the opaque bits, so that the OSK surface gets those touch events
[15:56] <AlbertA> greyback: it looks like the namespace changes actually are the culprit
[15:57] <AlbertA> greyback: I used your new branch
[15:57] <anpok_> o_O
[15:57] <AlbertA> greyback: if I just change the name of MirSurface instead, then focus issue is gone
[16:01] <kgunn> dandrader: ^ focus issue = osk issue on 0.1.6
[16:02] <kgunn> AlbertA: so you've done the clean-image-test, verified you're packages installed, and everything ?
[16:03] <AlbertA> kgunn: I'm manually installing (i.e. pushing with adb to /usr/lib)
[16:04] <kgunn> AlbertA: got it...but once you see it, then a dpkg -a to double check (...at least i think its -a)
[16:06] <greyback> anyone have a few minutes to review https://code.launchpad.net/~gerboland/unity-mir/namespace-to-prevent-collision2/+merge/209930 ?
[16:06] <greyback> AlbertA: odd. What have I screwed up...
[16:12] <dandrader> greyback, I can do it
[16:12] <greyback> okay, I'm just rebuilding to see
[16:13] <dandrader> greyback, btw unity-mir is clashing with what mir symbols specifically?
[16:14] <greyback> dandrader: "MirSurface"
[16:30] <dandrader> kgunn, so the mir branch to use for this bug is lp:~mir-team/mir/trunk-0.1.6 , right?
[16:31] <kgunn> dandrader: correct
[16:31] <kgunn> so...wanna join
[16:31] <kgunn> https://plus.google.com/hangouts/_/calendar/a2V2aW4uZ3VubkBjYW5vbmljYWwuY29t.2k4udqa2ovs931siq3b5fprgkc
[16:44] <anpok> dandrader: alf__ AlbertA: hmm had connection issues again..
[16:44] <anpok> Q_DECLARE_METATYPE seems to need some additional love..
[17:04] <dandrader> kgunn, so we have a unity-mir branch that renames MirSurface (instead of putting it in a namespace) and it solves bug 1289058 ?
[17:05] <anpok> dandrader: i think AlbertA does not have published one yet..
[17:05] <greyback> dandrader: that'll work I suppose. Why namespaces breaking it still mystifies me tho
[17:06] <anpok> https://bugreports.qt-project.org/browse/QTBUG-15459
[17:06] <anpok> greyback: ^
[17:06] <greyback> anpok: yep, I knew about that
[17:07] <greyback> but usually a nice loud error message accompanies that
[17:08] <kgunn> greyback: so dandrader says "we just shouldn't go there"
[17:08] <kgunn> :)
[17:09] <kgunn> i'm gonna leave that bug open tho....maybe it should go against Qt ?
[17:11] <greyback> kgunn: the fastest solution is that yes. Looks like a bug I can beat my head against for a day or two, something subtle with Qt/qml and namespaces
[17:11] <AlbertA> greyback: kgunn: I think we found the issue
[17:11] <AlbertA> greyback: kgunn: it is indeed the Q_PROPERTY in inputarea.h
[17:11] <AlbertA> Q_PROPERTY(MirSurface* surface READ surface WRITE setSurface NOTIFY surfaceChanged)
[17:11] <AlbertA> change to
[17:12] <AlbertA> Q_PROPERTY(unitymir::MirSurface* surface READ surface WRITE setSurface NOTIFY surfaceChanged)
[17:12] <greyback> ah feck
[17:13] <greyback> AlbertA: that's if
[17:13] <greyback> it
[17:13] <AlbertA> greyback: we need to do that for all Q_PROPERTY items
[17:13] <AlbertA> greyback: kgunn: yep confirmed on the n4
[17:15] <AlbertA> kgunn: greyback: so what do you want to do?
[17:16] <kgunn> AlbertA: wow...so if that confirms it, sounds like we should just poperly use the Q_PROPERTY
[17:16] <kgunn> ....unless, did dandrader|lunch say there was some other knock-on bug ?
[17:16] <greyback> AlbertA: I'm updating the namespace branches now
[17:17] <greyback> AlbertA: I reapproved your https://code.launchpad.net/~andreas-pokorny/unity-mir/fix-1240400/+merge/207302 since it was not to blame
[17:18] <greyback> anpok ^^
[17:18] <AlbertA> kgunn: well in this particular case
[17:19] <AlbertA> kgunn: there was no qt error
[17:19] <AlbertA> kgunn: because I suppose MirSurface * got resolved to Mir's version
[17:20] <kgunn> AlbertA: greyback anpok dandrader|lunch ...thanks all nice work, and so, the MP list should remain as it is...i'll just assume gerry's update will be on the original
[17:20] <kgunn> https://code.launchpad.net/~gerboland/unity-mir/namespace-to-prevent-collision/+merge/208645
[17:21] <greyback> kgunn: yep
[17:23] <greyback> ok fix pushed
[17:35] <dandrader> kgunn, using fully qualified names in all qt macros might solve all woes indeed. It's just that I've been bitten by such issues before thus I would rather avoid this namespace vigilance if possible
[17:36] <dandrader> AlbertA, kgunn and that includes all signal-slot connections and parameters as well, if I'm not mistaken
[17:39] <AlbertA> dandrader: just for my own curiosity, what sort of issues have you encountered? To they manifest as crashes? weird behavior? something else?
[17:42] <dandrader> AlbertA, a connection between a signal and a slot may fail, for instance (mismatching parameters due to namespace confusion). and that failure, depending on how you do that connection in C++, will fail silently at runtime
[17:42] <dandrader> AlbertA, but it was a while ago, so I don't recall details.
[17:52] <greyback> dandrader: well C++11 does give us nicer compile time signal/slot connections, which can help - it does parameter matching if I'm not mistaken
[17:52] <dandrader> greyback, yes
[17:53] <greyback> adding more symbols to the global namespace will inevitably cause collisions. namespaces necessary evil. They're tricksy with Qt annoyingly
[17:58] <anpok> hmm ok now the nexus 4 shows a black screen with a grey sign, red letters: Download Mode Do not unplug the device until the process is complete..
[17:58] <kdub> eh, its lying
[17:59] <kdub> probably just a wrong key combo when it was booting
[18:01] <anpok> k restarting
[18:10]  * greyback eow, but will be back online in a few
[18:52] <anpok> swapping the usb cable did the trick..