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