[01:24] <duflu> Oh look, Mir 0.26.0 released to zesty!
[09:40] <alan_g> greyback: I see you've opened the MirAL: Workspaces notes. Let me know when you've thought about it.
[09:41] <greyback> alan_g: sure
[09:41] <greyback> I'm chewing on it
[09:42] <greyback> all the fancy unity8 workspace per display stuff should work ok
[09:42] <duflu> I can see you hands waving from here
[09:42] <duflu> your
[09:42] <alan_g> Yeah, it took me some time to reach that division of responsibility too.
[09:43] <anpok_> greyback: workspace per display is the way it should be..
[09:43]  * duflu shrugs. Just do it well and see if the users agree
[09:44] <greyback> well moving workspaces beteen displays is the more complex part of the spec
[09:44] <greyback> but that can be done by simply keeping the workspace, and confining the windows on the desired display of that workspace
[09:45] <alan_g> and we understand how to do that in "policy"
[09:45] <greyback> right
[09:45] <greyback> alan_g: does your spec allow for a window to exist *not* on a workspace?
[09:46] <alan_g> greyback: yes, but the policy can add it to one in advise_new_window()
[09:47] <greyback> alan_g: because I'd consider the collection of windows not on a workspace to be equivalent to a workspace
[09:48] <alan_g> Yeah, I considered a default workspace, but I think it complicates things
[10:00] <greyback> could someone here comment on the correctness of this: https://code.launchpad.net/~ted/ubuntu-app-launch/mir-26/+merge/316173
[10:03]  * alan_g looks
[10:14] <duflu> greyback: I'm going to EOD instead, but equally could you sanity check this? https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1654915
[10:59] <dandrader> alan_g, oh no. mir 0.26 api revolution
[10:59] <dandrader> alan_g, what replaces SurfaceSpec::for_normal_surface nowadays?
[11:00] <alan_g> s/surface/window/g
[11:00] <alan_g> s/Wurface/Window/g
[11:00] <alan_g> s/Surface/Window/g
[11:02] <dandrader> alan_g, oh, so it's WindowSpec::for_normal_surface. I would expect WindowSpec::for_normal_window
[11:03] <alan_g> So would I...
[11:05] <alan_g> dandrader: I can fix that in the next release (it isn't part of the ABI)
[11:05] <dandrader> alan_g, ok
[11:15] <greyback> alan_g: one question you may have missed: https://docs.google.com/document/d/12jA76Pfjjg9HgiAJGGeOOi5OavaQaio9637tNiCBAgo/edit?disco=AAAABG6ocYI
[11:16] <alan_g> greyback: replied
[11:31] <dandrader> alan_g, there's also miral::toolkit::WindowSpec::create_surface
[11:32] <alan_g> dandrader: thanks. I must have missed checking that header.
[11:49] <taiebot> Hey was reading about mir 0.26 is there anyway to test this on mako running rc-proposed ?
[11:51] <alan_g> taiebot: if that's still vivid+overlay, then not supported.
[11:52] <taiebot> alan_g: yep sadly still vivid+overlay.
[11:57] <alan_g> taiebot: I know it's a frustrating transition, but we have to focus our limited resources on the future: 16.04LTS+overlay and 17.04
[12:45] <alan_g> greyback: just checking I've understood - input method windows don't (shouldn't) get input focus ever?
[12:45] <greyback> alan_g: for the simple case of the OSK - yes. For more general cases, I'm not 100% certain, but I think os
[12:46] <alan_g> Sounds right, just checking as I'm not 100% either
[12:47] <alan_g> Surprised you didn't MP the fix, bug report reads like you found the line that's wrong.
[13:58] <dandrader> alan_g, how do I set the initial MirWindowState using miral::toolkit::WindowSpec?
[13:59] <dandrader> alan_g, more specifically, I wanna create a fullscreen window
[14:03] <dandrader> alan_g, I guess it's missing a wrapper for mir_window_spec_set_state() ?
[14:12] <dandrader> alan_g, reported a bug
[15:06] <alan_g> dandrader|afk: there are missing wrappers, but in any case you can use it with mir_window_spec_set_state() - as the first argument