[03:09] <duflu> RAOF: Care to jam in a last minute review before this one lands?   https://code.launchpad.net/~vanvugt/mir/fix-1638774/+merge/309910
[03:09] <RAOF> duflu: Sure.
[03:12] <duflu> RAOF: Ta. I would write proper make_ functions if it was important but they're only tests which compare pointer values
[04:34] <RAOF> ???
[04:35] <RAOF> This backtrace makes no sense.
=== chihchun_afk is now known as chihchun
=== davmor2_HOLS is now known as davmor2
=== chihchun is now known as chihchun_afk
=== marcusto_ is now known as marcustomlinson
[12:02] <alan_g> greyback: fixed as requested, but should I port it over to lp:qtmir? https://code.launchpad.net/~alan-griffiths/miral/WindowControllerInterface-isVisible/+merge/310039
[12:05] <greyback> alan_g: great, thank you. Our current plan is the following: we moved all of lp:miral/miral-qt to  lp:~unity-team/qtmir/miral-qt-integration - we are developing on top of this branch, making MPs on top of it, and merging manually
[12:06] <greyback> alan_g: I think it would be logical to remove lp:miral/miral-qt - less duplication. wdyt?
[12:08] <alan_g> greyback: Agreed. There should only be one. I think I'll stop poking at that code for a while to minimise churn.
[12:12] <alan_g> greyback: there are a couple of [miral-qt] MPs in flight (including the one I asked about). What's the plan for them?
[12:12] <greyback> alan_g: we'll integrate them into our branch
[12:14]  * alan_g decides its SEP for the next week or so. ;)
[12:19] <greyback> alan_g: ok, I've cleaned up the MP list. Aside from your branch, everything else has been included in lp:~unity-team/qtmir/miral-qt-integration
[12:19] <greyback> "SEP" ?
[12:19] <alan_g> Someone Else's Problem
[12:19] <greyback> :)
[12:22] <alan_g> Will you pick up my PM too?
[12:22] <alan_g> Ah, just see comment
[12:22] <alan_g> *seen
[12:46] <alan_g> sil2100: can I talk you into landing this? https://bileto.ubuntu.com/#/ticket/2155
=== hikiko is now known as hikiko|ln
[12:55] <sil2100> alan_g: sure, let me take a look
[13:02] <sil2100> alan_g: done
[13:02] <alan_g> sil2100: thanks
=== alan_g is now known as alan_g|lunch
=== dandrader is now known as dandrader|afk
=== marcust__ is now known as marcustomlinson
=== hikiko|ln is now known as hikiko
=== dandrader|afk is now known as dandrader
=== alan_g|lunch is now known as alan_g
[14:29] <dandrader> greyback, you there?
[14:31] <dandrader> alan_g, I suppose you eventually want to remove that from miral::Window? "operator std::shared_ptr<mir::scene::Surface>() const;"
[14:32] <alan_g> dandrader: no, it's needed internally (or something equivalent) and I don't want to ban use of it, just make it mostly unnecessary.
[14:58] <alan_g> dandrader: I assume you're good with this: https://code.launchpad.net/~alan-griffiths/miral/purge-miral-qt/+merge/310192
[15:00]  * dandrader looks
[15:38] <alan_g> bschaefer: not tried snapping it yet, but a POC https://github.com/AlanGriffiths/mircade
[15:39] <bschaefer> alan_g, ooo very nice
[15:39]  * bschaefer tries it
[15:40] <bschaefer> game not found, but i have a few others :)
[15:41] <alan_g> Yeah, there's a few bits need writing
[15:41] <bschaefer> yeah, but nice looking
[15:42]  * bschaefer was going to start looking at emulation station on his half days
[15:43] <bschaefer> alan_g, also, the games werent fullscreen when i started them
[15:43] <bschaefer> could be one of those things that just need extra writing :)
[15:44] <alan_g> bschaefer: I noticed that too. Was wondering if miral-kiosk ought to force fullscreen
[15:44]  * bschaefer thinks thats a good choice
[15:45] <alan_g> The question is "when?" - obviously not for *all* windows
[15:45] <bschaefer> o true hmm
[15:45] <alan_g> Ones without parents? The first one?
[15:46] <alan_g> (First for the app)
[15:46] <bschaefer> alan_g, possibly yeah the first? Right after your exec command?
[15:47] <bschaefer> well i guess you already do then :)
[15:47] <bschaefer>             mir_surface_set_state(surface, mir_surface_state_fullscreen);
[15:47] <bschaefer> but i suppose you'll need to apply the spec
[15:47] <alan_g> bschaefer: that's just the mircade client, It can't fiddle with other applications
[15:47] <bschaefer> (but not sure if you have access to the mir surface for it)
[15:47] <bschaefer> yeah
[15:48] <bschaefer> alan_g, can you always force fullscreen for *new* cleans only?
[15:48] <bschaefer> not sure what would happen with something like gimp though
[15:49] <alan_g> miral-kiosk can do whatever I decide
[15:49] <bschaefer> :)
[15:49] <alan_g> apps with a "splash" screen could also be "difficult"
[15:49] <bschaefer> o right...
[15:50]  * alan_g wonders what surface type they are
[15:50] <bschaefer> thats left up to the client :)
[15:50] <bschaefer> (ie. could we depend on it? being a specific type?)
[15:51]  * alan_g is tempted by "type=normal, parent=(none)" => fullscreen
[15:52] <bschaefer> that seems far... i suppose there could be a few edge cases
=== dandrader is now known as dandrader|afk
[15:53] <alan_g> Yeah, but "kiosk" isn't intended as a fully functional desktop
[15:54] <bschaefer> exactly, i think thats a fair assumption to put on
[15:54] <bschaefer> alan_g, i can only think of a couple cases? *Such as gimp but you can force 1 window IIRC*
[15:55]  * alan_g doesn't think running gimp on a "kiosk" needs to be supported
[15:55] <bschaefer> yeah
[15:55] <bschaefer> but maybe a *drawing* station haha
[15:55] <alan_g> kgunn might disagree
[15:55] <bschaefer> with touch (idk if its even supported)
[16:02] <kgunn> yeah, i wouldn't think gimp kiosk would be a top seller ;)
[16:04] <alan_g> kgunn: bschaefer and I have been discussing using miral-kiosk for an "arcade" style interface and for that scenario it makes sense to force "fullscreen" for main windows (for some definition of main window)
[16:04] <anpok> hm I have a photo of an ubuntu drawing kiosk in a sport cloth shop
[16:05] <bschaefer> alan_g, yeah i think thats a good way to go... i cant think of anything else that would be *strange* but i suppose they are out there!
[16:07] <kgunn> anpok: was that gimp? :)
[16:07] <anpok> hm nope..
=== dandrader|afk is now known as dandrader
[17:27] <attente> anpok: hey, do you know what's happening with keymap support? is the shell taking over there?
[17:27] <attente> or is the client still expected to do the key event translation?
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[21:17] <anpok> attente: yes .. the shell is in charge.. i.e the shell is now able to configure the keymapping per keyboard in its own process, it will receive mapped keys including compose key results
[21:17] <anpok> attente: but it still could configure client windows to have different keymap
[21:17] <anpok> (again per keyboard)
[21:19] <attente> anpok: i don't understand, does that mean clients could both receive already translated key events and non-translated key events as well?
[21:19] <anpok> they get enough information yes..
[21:19] <anpok> key events contain the original scan code and the mapped key
[21:19] <attente> ah, ok
[21:19] <attente> thanks!
[21:20] <anpok> and for the forseeable future - due to xmir - unity8 will configure keymaps for client windows