[00:49] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [pull request #2702](https://github.com/MirServer/mir/pull/2702): ThreadPoolExecutor: Drop std::binary_semaphore polyfill.
[00:49] -GitHub[m]:#mir-server-  
[00:49] -GitHub[m]:#mir-server- > All targets we compile for should now support enough C++20 stdlib features to remove the need for us to provide a fallback.
[03:07] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF added no-merge to [pull request #2702](https://github.com/MirServer/mir/pull/2702): ThreadPoolExecutor: Drop std::binary_semaphore polyfill.
[10:20] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq merged [pull request #2693](https://github.com/MirServer/mir/pull/2693): Fix compilation failure with GCC-12 (missing headers)
[10:47] <Saviq> alan_g hey, got preference on how should the placement be solved for the "fill all screens" behaviour in Frame? I could think of two ways:
[10:47] <Saviq> 1. on placing a new window, try and find an empty output
[10:47] <Saviq> 2. maintain a list of outputs / logical groups and their "busy" state
[10:47] <Saviq> On the one hand, 2. feels more correct, but a lot more complex, tracking windows and outputs
[10:48] <Saviq> Where 1. would be simpler, but more "wasteful"; then again it's not a hot path at all
[10:48] <alan_g[m]> I'd go for the simple: `output_id++ % noutputs`
[10:49] <Saviq> Right, so even simpler. Works for me.
[10:50] <Saviq> Hmm. Except output groups.
[10:57] <Saviq> So I'd have to maintain a list of display areas, ~~stealing~~ reimplementing some of https://github.com/MirServer/mir/pull/1756/files to cycle through the display areas rather than outputs (which would end up overlaying $group_output_count on top of one another)
[10:58] <Saviq> *otherwise
[11:04] <Saviq> Or modify `BasicWindowManager` in a way to expose the display areas…
[11:04] <Saviq> **or** implement this whole behaviour in `BasicWindowManager` in the first place, but I'm not sure it should be the default…
[11:33] <Saviq> So many options… WDYT?
[11:33] <alan_g[m]> It shouldn't be the default.
[11:35] <alan_g[m]> Really, without coordination between the display layout display assignment, you can't get everything right all the time. So I'd do the simplest thing as suggested above
[11:36] <Saviq> Right, and we have a better approach planned next cycle, so maybe that's OK.
[12:01] <alan_g[m]> So, maybe put it all behind a switch that forces a side-by-side layout and activates the round-robin assignment
[12:01] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [pull request #2703](https://github.com/MirServer/mir/pull/2703): Add some tests for recent changes
[12:10] <Saviq> <alan_g[m]> "So, maybe put it all behind a..." <- Should I just bring `miral::display_configuration_options` into Frame?
[12:11] <Saviq> Though that could conflict with the existing `--display-layout` option somewhat
[13:02] <alan_g[m]> Quite
[13:20] <alan_g[m]> Saviq, re our discussions about the WM policy inserting an output_id into window modifications. Do you think that if an output is specified then it should affect the placement of restored, vert-maximized and horiz-maximized windows?
[13:23] <Saviq> I think it should, since it's the shell doing it, it could well just place it on its own, but if this can be common, it should be
[13:25] <alan_g[m]> I think so too, but thought I'd confirm before spending time on it
[13:54] <Saviq> alan_g it's only the help text that really conflicts, isn't it:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/11f1145dcd6e7e613d77ab8359cd57c691109069>)
[13:55] <Saviq> In fact, that there isn't a `--display-layout` in `miral::display_configuration_options` looks like an ommission?
[13:55] <Saviq> And it would just be a case of defaulting to `--display-config static=…` in Frame to keep current behaviour
[14:03] <alan_g[m]> What do you mean "really conflicts"?
[14:04] <Saviq> I mean, `--display-layout` complements `--display-config static=…`
[14:05] <Saviq> But the implementations do conflict of course
[14:07] <Saviq> That we have both `miral::display_configuration_options` and `miral::DisplayConfiguration` is confusing
[14:10] <alan_g[m]> Yes, it is confusing and not very flexible, but we've not been motivated to fix it yet
[14:14] <Saviq> alan_g would you oppose this round-robin behaviour being default in Frame? The only case where I think it would do something unexpected is when you have overlapping outputs (our current definition of clone) of different dimensions, which in itself is a somewhat broken scenario
[14:15] <grayson-g[m]> Good morning, y'all! Rested and ready to get back at it.
[14:16] <alan_g[m]> Well, isn't the default in Frame "clone"?
[14:17] <alan_g[m]> grayson-g welcome back!
[14:17] <Saviq> alan_g[m]: Yes, but round-robin on clone (of same dimensions) would just place the windows as it does today, on top of one other
[14:19] <Saviq> If overlapping displays of different dimensions, the result would be different, yes, but current behaviour is wrong, new behaviour would just make it wrong differently
[14:21] <alan_g[m]> Ack
[14:41] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** Saviq opened [pull request #90](https://github.com/MirServer/ubuntu-frame/pull/90): wm: place windows round-robin on all displays... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/a887f8a84d89ce1ca072f64ce198e2b5e98f9221>)
[14:41] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** Saviq requested a review from AlanGriffiths for [pull request #90](https://github.com/MirServer/ubuntu-frame/pull/90): wm: place windows round-robin on all displays
[15:37] <grayson-g[m]> I've got a GMock question:
[15:37] <grayson-g[m]> In the tests I've been writing for exposing wait features, I have two tests that check if a watch on a signal triggers a callback if the signal is readable (one test registers the signal before the Server is started, the other is after). I have two similar tests for file descriptors. Infrequently all 4 tests pass in one run, but usually certain tests pass and others don't (fd tests more likely to pass than signal tests).
[15:37] <grayson-g[m]> What I've noticed is if I put a bunch of `puts()` statements at the end of the tests to buy more time until the test finishes, they're much more likely to pass. Is there a way to delay a test for a set period of time to ensure that the MainLoop has run enough cycles to trigger the callback?
[15:37] <grayson-g[m]> (I only assume that's the issue. There may also be a race condition somewhere, but it doesn't appear to be in my tests.)
[15:40] <alan_g[m]> grayson-g it is a very bad idea to use delays as a substitute for proper synchronization. If there's a need for additional synchronization, then that needs to be designed and implemented
[15:41] <alan_g[m]> So, can you, for example, use a `condition_variable` and notify that from an action queued to the main loop
[15:45] <alan_g[m]> Doing that in, say, `TearDown()` should ensure that the main loop is quescent by the time the test ends
[15:45] <grayson-g[m]> alan_g[m]: I can do that!
[16:34] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** AlanGriffiths self-requested a review for [pull request #90](https://github.com/MirServer/ubuntu-frame/pull/90): wm: place windows round-robin on all displays
[16:41] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** bors[bot] edited [pull request #90](https://github.com/MirServer/ubuntu-frame/pull/90): [Merged by Bors] - wm: place windows round-robin on all displays
[16:41] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** bors[bot] closed [pull request #90](https://github.com/MirServer/ubuntu-frame/pull/90): [Merged by Bors] - wm: place windows round-robin on all displays
[16:50] <Saviq> Good night, see you all in full force tomorrow o/
[16:55] <alan_g[m]> And it's goodbye from me! o/
[18:09] -GitHub[m]:#mir-server- **[MirServer/mir]** graysonguarino opened [pull request #2704](https://github.com/MirServer/mir/pull/2704): Don't use "wayland-host" as command line option example
[18:09] -GitHub[m]:#mir-server-  
[18:09] -GitHub[m]:#mir-server- > Since "wayland-host" is an option only provided by the Wayland platform, it makes more sense to present an example option that is existent on all platforms. This uses "wayland-extensions" instead as an example. Fixes #2687
[18:09] -GitHub[m]:#mir-server- **[MirServer/mir]** graysonguarino edited [pull request #2704](https://github.com/MirServer/mir/pull/2704): Don't use "wayland-host" as command line option example
[19:41] -GitHub[m]:#mir-server- **[MirServer/mir]** graysonguarino opened [pull request #2705](https://github.com/MirServer/mir/pull/2705): Change mmap to MAP_PRIVATE in example clients
[19:41] -GitHub[m]:#mir-server-  
[19:41] -GitHub[m]:#mir-server- > Fixes #2534