[06:33] <RAOF> Hm.
[06:33] <RAOF> It occurs to me that what I really want is mir::observing_ptr.
[06:41] <racarr_> ALL ABOARD THE MIR TRAIN
[06:41] <racarr_> DEPARTURE SOON
[06:41] <racarr_> *whistle blowing*
[06:42] <racarr_> Happy new years everyone :) See you all tomorrow.
[07:54] <mlankhorst> Morning and happy newyear
[07:54] <mlankhorst> RAOF: don't we all want that? :D
[13:04] <kdub> good morning
[13:43] <greyback_> alan_g: hello! Happy New Year to you
[13:44] <greyback_> quick question, the new mir Server api doesn't have a getter for the_placement_strategy - omission or intentional?
[14:03] <alan_g> greyback_: Healthy New Year!
[14:03] <kgunn> mornin' & happy new year to all
[14:04] <greyback_> o/
[14:04] <alan_g> We've exposed the stuff that is in use
[14:04] <alan_g> kdub: kgunn : Healthy New Year!
[14:05] <kdub> alan_g, thanks
[14:11] <greyback_> alan_g: https://bugs.launchpad.net/mir/+bug/1407687 - I'd like it re-instated as I've a qtmir patch to use it. Far from urgent tho
[14:25] <kgunn> camako: seems like we should probably cherry pick this into stable
[14:25] <kgunn> https://code.launchpad.net/~vanvugt/mir/fix-1401488/+merge/245443
[14:26]  * camako looks
[14:26] <kgunn> ...lemme know what ya think
[14:26] <kgunn> showing up here also
[14:26] <kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1405687
[14:26] <kgunn> ...with people confirming
[14:27] <camako> kgunn, yeah I think so
[14:27]  * kdub wonders why we're wrapping the binaries
[14:28] <camako> kgunn, we'll be making a release though.. will start it today..
[14:28] <kgunn> cool
[14:36] <alan_g> kdub: wrapping is an [in]elegant way to locate the platforms directory
[14:40] <kdub> yeah... guess its too late to object
[14:43] <alan_g> If I (or duflu) had had a better idea then we would have objected
[14:47] <kdub> yeah, something to improve on later
[15:17] <racarr_> Good morning
[15:17] <kdub> morning racarr_
[15:19] <camako> morning
[15:20] <racarr_> hey :) Happy new years guys
[15:21] <camako> happy new year to you too :-)
[15:29] <attente_> hello, is mir supposed to generate hover-exit motion events when the mouse cursor leaves a surface?
[15:33] <racarr_> sort of yes
[15:33] <racarr_> as it stands cursor stuff doesnt work very well espescially under unity8
[15:34] <racarr_> qtmir will drop the hover exit event afairc (it would be hard for it to know what to do with it currently atm)
[15:38] <greyback_> qtmir is missing many useful mouse events yet
[15:38] <greyback_> so yeah, is on the list
[15:40] <kgunn> racarr_: happy new year
[15:41] <alan_g> camako: racarr_ Healthy New Year!
[15:48] <racarr_> MirPointerEvent coming soon :)
[15:48] <racarr_> PointerInputEvent rather
[16:14] <racarr_> maybe this is a good time to inbox 0
[16:15] <racarr_> BOOM
[16:15] <kgunn> good luck
[16:16] <kgunn> ....you'll likely get stuck on the riveting cla email
[16:21] <alan_g> greyback_: I'm curious: how is the_placement_strategy() useful outside of Mir? Is it a workaround for a better API?
[16:24] <greyback_> alan_g: I want to push the placement decision into qml. I do this by making the place() call emit a synchroneous signal, that qml can catch and make the decision
[16:25] <greyback_> alan_g: https://code.launchpad.net/~gerboland/qtmir/initialSurfaceGeometry/+merge/231725 is how I'm using it
[16:26] <alan_g> greyback_: OK but that just needs override (which is supported).
[16:26] <alan_g> I'll take a look
[16:26] <greyback_> alan_g: yeah, my workaround is just to save a copy of the shared pointer to the PlacementStrategy
[16:26] <greyback_> ...in the override
[16:28] <alan_g> I think it is similar to my saving the WindowManager in https://code.launchpad.net/~alan-griffiths/mir/tiling-window-mamagement/+merge/245228 (but I want the WindowManager, not the PlacementStrategy interface
[16:37] <greyback_> alan_g: yes indeed. I've always let Mir create the objects and then relied on getters for them (not doing this was buggy with the old api). Perhaps I should relax that now
[16:39] <alan_g> greyback_: it seems you actually want a MirPlacementStrategy* (not a ms::MirPlacementStrategy). So, rather than an accessor in Mir and a downcast (BTW wouldn't dynamic_cast be safer?), why not keep a weak_ptr<MirPlacementStrategy>? That would automatically give you your nullptr too.
[16:40] <greyback_> alan_g: fair point, and yes fair point
[16:41] <alan_g> Can I mark lp:1407687 invalid?
[16:42] <greyback_> alan_g: just an FYI on why I'm implementing ms::MirPlacementStrategy - I received complaints from some clients where the surface size returned by the PlacementStrategy would be changed later when the surface is added to the scene. I.e. the surface would get a resize event shortly after creation. Some clients don't like that
[16:42] <alan_g> that seems sensible
[16:43] <alan_g> And what ms::PlacementStrategy is for
[16:43] <greyback_> alan_g: you can. But it does open up a slight API inconsistency in mir::Server - as many overrides do have accessor methods, and only a few do not
[16:44]  * greyback_ not sure "accessor" is the correct term
[16:46] <alan_g> "accessor" or "factory method" or ...
[16:46] <greyback_> ack
[16:48] <alan_g> I'd rather only expose things that are actually useful
[16:49] <greyback_> that fair. I'm not that opinionated on this, just wanted to raise the question as to how you expect the api to be used
[16:51] <alan_g> Sure. I'm not opinionated either. The interface is already public so there's little cost to exposing it - except that folks might use it (and write bad code).
[16:52] <greyback_> I'll let you have the final call so.
[16:56] <alan_g> Do you have an opinion on my example above? After writing my WindowManager example code think there's too much "wiring" in the example and not enough in the library. (I could push the "Tracker" and "Factory" wiring into Mir and give it a msh::WindowManger interface)
[17:04] <greyback_> I do like the basic design of WindowManager, and think TilingWindowManager is a nicely written bit of example code. It is a bit surprising for me that different methods of WindowManager will be called in different threads tho, but as long as that's clearly documented it is fine
[17:05] <greyback_> yeah the tracker is pretty typical, I had expected it to be in Mir
[17:06] <greyback_> if you intend to push WindowManager into Mir, then yeah think it logical the Trackers will have to go in too
[17:07] <attente_> will mir support the same kind of pointer hover enter/exit behaviour as in X? per http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html
[17:08] <racarr_> attente_: Yes
[17:09] <alan_g> I'm not sure the design is yet mature enough to put in the API (e.g. no focus switching) but it does seem to be that stuff is missing that would make Mir usable.
[17:09] <racarr_> attente_: Currently support is spotty, I guess it wont work under unity8 and should work otherwise
[17:09] <racarr_> soon it will work fine :)
[17:10] <attente_> racarr_: thanks!
[17:10] <greyback_> racarr_: qtmir/unity8 will generate the hover enter/exit events for the client, if mir supports such an event
[17:11] <racarr_> greyback_: DO you think so? I think it will drop it in QtEventFeeder
[17:12] <racarr_> the bit that
[17:12] <racarr_> switches based on the touch action
[17:12] <racarr_> just drops hover enter/exit afairc
[17:13] <racarr_> QtEventFeeder::dispatchMotion...are you saying they are then
[17:13] <racarr_> generated again later?
[17:14] <greyback_> racarr_: we'll generate them in the MirSurfaceItem - which lives in our scene and knows when mouse in/out occurs
[17:14] <racarr_> oh
[17:14] <racarr_> future perfect
[17:14] <racarr_> will
[17:14] <racarr_> not
[17:14] <racarr_> present perfect
[17:14] <racarr_> will
[17:14] <racarr_> haha
[17:14] <greyback_> yes sorry
[17:15] <racarr_> No its ok :p yea
[17:15] <racarr_> h
[17:15] <racarr_> that is where to do it. nothing atm I think though
[17:15] <greyback_> Hayy New Year btw!
[17:15] <racarr_> Happy new year!
[17:15] <racarr_> There are some pointer event changes upcoming that should make this possible to implement correctly
[17:15] <racarr_> currently you cant really differentiate between
[17:15] <racarr_> touch points hovering
[17:15] <racarr_> and the pointer
[17:15] <greyback_> yeah, mouse support need work still, will be dandrader's first mission when back
[17:16] <racarr_> ah cool
[17:16] <racarr_> im cleaning up the mir end :)
[17:16] <racarr_> SYNERGY
[17:16] <greyback_> nice
[17:16] <greyback_> it could do with it
[17:16] <greyback_> any idea how's the libinput integration going too?
[17:16] <racarr_> new model is touch/pointer event are seperate event types
[17:16] <racarr_> hmm
[17:16] <racarr_> not really
[17:16] <racarr_> definitely some progress on the
[17:17] <racarr_> infrastructure to
[17:17] <greyback_> +1 for the different event types anyway
[17:17] <racarr_> well like support libinput based devices and
[17:17] <racarr_> also use the android stack
[17:17] <racarr_> etc
[17:17] <greyback_> gotcha
[17:17] <racarr_> I wouldnt be expecting 2 finger scroll this month though :(
[17:17] <racarr_> maybe thats pessimistic or anpok was working over holidays or something lol
[17:18] <racarr_> greyback_: Did you have nice holidays?
[17:19] <greyback_> racarr_: yeah, was the perfect length to forget everything work related
[17:19] <greyback_> you?
[17:19] <greyback_> see the family?
[17:19] <racarr_> Yeah excellent :D Also forgot everything. Went to see family
[17:19] <racarr_> they gave me a violin
[17:19] <racarr_> A+!
[17:23] <greyback_> nice!
[17:23] <greyback_> I wouldn't like to be your neighbor right now...
[17:24] <greyback_> we have an old family violin which my mother used to play when she was young. We got it restored and gave it to my sister's daughter
[17:24] <greyback_> ofc no such thing as a free gift - she's now eternally obliged to play it at family gatherings :)
[17:36] <racarr_> hehe of course
[17:57] <alan_g> racarr_: kdub I could do with another vote on https://code.launchpad.net/~alan-griffiths/mir/tiling-window-mamagement/+merge/245228
[17:57] <kdub> alan_g, okay
[18:00] <kdub> alan_g, will review probably after your EOD, my brain is spooled up with how to improve android display construction
[18:01] <alan_g|EOD> kdub: np
[18:14] <racarr_> wow this vacation stuff
[18:14] <racarr_> really works
[18:14] <racarr_> I actually had fun reviewing the managed surface branch
[18:16]  * alan_g|EOD thinks he needs a vacation then
[18:28] <racarr_> I think its ok to land this yeah? https://code.launchpad.net/~mir-team/mir/port-examples-off-mir-event-access/+merge/245240
[18:32] <racarr_> hmm I guess anpok is still gone
[18:40] <racarr_> evdev-input-platform isnt easy
[19:48] <racarr_> Finished reviews gonna take a niec long lunch
[19:48] <racarr_> back in ~1 hour
[21:08] <kgunn> camako: are we fully swtiched over from asio to glib mainloop?
[21:08] <kgunn> ...guessing not on rtm
[21:08] <camako> kgunn, yes
[21:09] <camako> kgunn, correct .. not on rtm
[22:58] <kgunn> kdub: for "Make nested & offscreen an actual platform" it's marked ready for release...so we really have a sw FB for offscreen on devel ?
[23:02] <RAOF> That would be pretty rad.
[23:04] <racarr_> Hi RAOF!
[23:04] <racarr_> Happy new years :D
[23:04] <RAOF> racarr_: Happy new year!