WEBVTT 00:00.000 --> 00:10.000 All right, hello everybody, can you help me hear me all right? 00:10.000 --> 00:14.000 I'm Isaac, welcome to my talk, separating the wailing compositor and wind manager. 00:14.000 --> 00:18.000 So if you're not familiar with me already, I'm the author of the River Wailing compositor. 00:18.000 --> 00:21.000 I'm working on it for like five or six years now. 00:21.000 --> 00:24.000 And for a long time it's just been like a nice dynamic tiling wind manager. 00:24.000 --> 00:29.000 But if there's one thing I've learned working on it is that people are very strong opinions about how their wind managers would work. 00:29.000 --> 00:32.000 And in myself included, any opinions change over time. 00:32.000 --> 00:37.000 And so I've been wanting to try out new things for myself without breaking things for this in users. 00:37.000 --> 00:46.000 I'm going to break some things, but what this will result in is a new compositor architecture that allows people to experiment much more easily with new wind management paradigms. 00:46.000 --> 00:48.000 I'm also a WRUS developer. 00:48.000 --> 00:54.000 I'm very thankful for the WRUS project, because it does a lot of things make my job writing river a lot easier. 00:54.000 --> 00:58.000 Direct scanner works great through WRUS without marriage effort on my end. 00:58.000 --> 01:00.000 And even in color management completely for me. 01:00.000 --> 01:03.000 I don't do any extra work or a small amount of extra glue code. 01:03.000 --> 01:05.000 But it does a lot of heavy lifting for river. 01:05.000 --> 01:07.000 I'm also a ZIG core team member. 01:07.000 --> 01:10.000 The stock's not going to be about ZIG at all, but ZIG's a great programming language. 01:10.000 --> 01:11.000 And you should check it out. 01:11.000 --> 01:14.000 So who here has seen this diagram before? 01:14.000 --> 01:16.000 I saw it from the wailing docks. 01:16.000 --> 01:22.000 This is how wailing decides structure the architecture of the building. 01:22.000 --> 01:24.000 It's a splacer of a compositor and window manager. 01:24.000 --> 01:28.000 You really need to see this to be explained a little bit. 01:28.000 --> 01:30.000 The name was not familiar with wailing at all. 01:30.000 --> 01:33.000 Wailing clients are your web browser, your terminal emulator. 01:33.000 --> 01:36.000 Everything that wants to display a window in your desktop environment. 01:36.000 --> 01:38.000 And then needs to get input events from the kernel. 01:38.000 --> 01:41.000 And then send a buffer to your display server, compositor. 01:41.000 --> 01:43.000 You get displayed in the screen. 01:43.000 --> 01:47.000 And so there's only one program that can get input events from the kernel at the same time. 01:47.000 --> 01:48.000 And then display buffers. 01:48.000 --> 01:50.000 You have to be one, just one programming doing that. 01:50.000 --> 01:52.000 Otherwise there's no way to coordinate things. 01:52.000 --> 01:53.000 And so that's the wailing compositor. 01:53.000 --> 01:57.000 For example, gnome, kd, slay, river, classic, et cetera. 01:57.000 --> 01:59.000 And really, this is three programs in one though. 01:59.000 --> 02:03.000 It's the display server, the compositor, and a window manager. 02:03.000 --> 02:06.000 And so it's making these distinctions a bit clearer. 02:06.000 --> 02:10.000 The display server job is just rounding input events from the kernel from windows. 02:10.000 --> 02:13.000 And then passing a buffer to the kernel to get rendered. 02:13.000 --> 02:14.000 That's what the display server does. 02:15.000 --> 02:20.000 The compositor is the part that combines many buffers from windows into a single scene. 02:20.000 --> 02:23.000 And a single buffer that can be displayed by the display server. 02:23.000 --> 02:27.000 And the window manager is responsible for arranging windows to finding key bindings, 02:27.000 --> 02:32.000 kind of providing your user experience of how you interact with your compositor in the display server. 02:32.000 --> 02:35.000 So before we talk about splitting the within the visitor, 02:35.000 --> 02:40.000 we need to find out why the wind decided to combine these things in the first place. 02:40.000 --> 02:44.000 And really, wind was motivated by combining the display server in the compositor. 02:44.000 --> 02:45.000 It wasn't really caring about the window manager. 02:45.000 --> 02:50.000 That's just kind of mixed in there because it was easier to do with that way, I guess. 02:50.000 --> 02:52.000 And so I understand why wind can combine these things. 02:52.000 --> 02:54.000 Me and go back and look at x11. 02:54.000 --> 02:57.000 So this diagram is also taking the wind up set of course. 02:57.000 --> 03:06.000 And it's making the points that the path that input events take to get a new buff thing running on your screen is quite complicated on x. 03:07.000 --> 03:09.000 We start up with the kernel. 03:09.000 --> 03:13.000 We're an independent pass pass through the EVVF API through your x server. 03:13.000 --> 03:14.000 That's the display server. 03:14.000 --> 03:18.000 Then there's already a problem here because the x server does not know the compositor's scene graph. 03:18.000 --> 03:21.000 And so it can't really route this input to the right window properly. 03:21.000 --> 03:23.000 But it can bring a pretty good guess. 03:23.000 --> 03:26.000 And so it sends it off to an x window, the x clients. 03:26.000 --> 03:30.000 This client will then respond by sending a render request to the x server. 03:30.000 --> 03:32.000 But the x server is not responsible for rendering things. 03:32.000 --> 03:35.000 And so then it has to send this request off to the compositor. 03:35.000 --> 03:38.000 Render a new buffer and send it back to the x server. 03:38.000 --> 03:41.000 Which can then finally get sent to the kernel and be displayed in your screen. 03:41.000 --> 03:43.000 And this actually adds a lot of latency. 03:43.000 --> 03:45.000 Because there's an extra round trip to the compositor. 03:45.000 --> 03:50.000 And things just don't work quite as well because there's not much integration between the compositor and the x server with the x server. 03:50.000 --> 03:53.000 Not being aware of the compositor's scene graph. 03:53.000 --> 03:59.000 And the window manager here could be just another x client or it could be part of the compositor as a compositing window manager. 03:59.000 --> 04:02.000 Which could be more common as x got more evolved. 04:03.000 --> 04:08.000 And so way then improves on this quite a bit by simplifying things and moving everything into one program. 04:08.000 --> 04:12.000 And so now you don't have a problem of the compositor not knowing about the, the place that we're not knowing about the compositor's scene graph. 04:12.000 --> 04:14.000 Because the display server and compositor are one thing. 04:14.000 --> 04:20.000 And so it's very easy for the way the compositor displays server combination throughout the input event to the right way and client. 04:20.000 --> 04:25.000 And there's no extra round trip of latency when rendering because the quad veteran's place or a one program. 04:25.000 --> 04:29.000 However, there's not really a need for the window manager to be combining here. 04:29.000 --> 04:34.000 But so that's to summarize the benefits of wayland over x11. 04:34.000 --> 04:39.000 x11 got embarrassing flickering flashing and tearing that we can get rid of with a better architecture. 04:39.000 --> 04:44.000 And there's an extra round trip every frame to the talk between the splacer and the compositor which does not need to happen. 04:44.000 --> 04:47.000 And wayland we have the every frame is perfect ideal. 04:47.000 --> 04:52.000 It's possible when you're wayland programs are well written and your compositor is well written that every frame looks perfect. 04:52.000 --> 04:56.000 There's no extra flickering or flashing or half render things are tearing. 04:56.000 --> 04:59.000 And there's no extra round trips, the architecture works well. 04:59.000 --> 05:02.000 And this policy or mechanism is a bit divisive in some ways. 05:02.000 --> 05:12.000 Like people like, excuse me, people like the extra control of policy of mechanism of a policy in x. 05:12.000 --> 05:14.000 Every program can kind of do lots of different things. 05:14.000 --> 05:16.000 It has lots of tools and school box. 05:16.000 --> 05:20.000 But this causes problems and lots of programs have competing interests. 05:20.000 --> 05:25.000 If a pop up on your screen, a screen like a cannot run at the same time because the pop up is already captured all input. 05:25.000 --> 05:28.000 From all devices and this causes problems. 05:28.000 --> 05:33.000 So policy or mechanism in wayland centralizes the power in the compositor essentially. 05:33.000 --> 05:37.000 All the programs can describe what they want to do and the compositors are responsible for carrying it out. 05:37.000 --> 05:40.000 And this makes impositor authors very happy because they get the end decisions. 05:40.000 --> 05:45.000 But this makes users less tapping some places because they cannot go on the time to write a full compositor perhaps. 05:45.000 --> 05:52.000 And so part of my work here is to make put this power very quickly by policy or mechanism back into the hands of users. 05:53.000 --> 05:59.000 And so the big downside I see of waysland compared to x is architecture is that writing wind and measure means writing out ways. 05:59.000 --> 06:01.000 This place over a compositor as well. 06:01.000 --> 06:02.000 It's never really way to get around that. 06:02.000 --> 06:04.000 You can use libraries to help you out. 06:04.000 --> 06:08.000 But you still have to debug a low level process component system component. 06:08.000 --> 06:11.000 But if a crash is, we'll send you back to you. 06:11.000 --> 06:12.000 The terminal. 06:12.000 --> 06:15.000 You have the TTY or maybe just like brick to your computer. 06:15.000 --> 06:16.000 I don't know. 06:16.000 --> 06:21.000 You might need a hardware build if you read your wind and measure wrong because it's a place over to. 06:21.000 --> 06:28.000 So where I'm going with this talk is a new architecture for wayland where we have a stable wayland protocol called river wind management v1. 06:28.000 --> 06:32.000 And as you separate the wind and wave and compositor in the wind and measure. 06:32.000 --> 06:35.000 The wayland compositor in this place over are still one components. 06:35.000 --> 06:40.000 We do not lose any of the benefits we get from compared to x11. 06:40.000 --> 06:42.000 So these are my design constraints. 06:42.000 --> 06:45.000 Basically we don't want to regress any of the improvements that has made over x11. 06:45.000 --> 06:47.000 Every stain must still be perfect. 06:48.000 --> 06:50.000 We want to minimally impact latency. 06:50.000 --> 06:55.000 That means that there should never be a round trip required every frame or every input event. 06:55.000 --> 07:02.000 And so to implement these constraints, my wind management protocol divides the state. 07:02.000 --> 07:05.000 The wind manager has control over into two separate categories. 07:05.000 --> 07:07.000 First we have wind management state. 07:07.000 --> 07:12.000 This includes wind dimensions, full screen state, keyboard focus, key bindings. 07:12.000 --> 07:16.000 These are all bits of state that the wind manager that the compositor needs to communicate with every winder. 07:16.000 --> 07:21.000 And so this requires synchronization with other windows. 07:21.000 --> 07:25.000 Well, rendering state in the other hand is state that only effects the final rendered buffer. 07:25.000 --> 07:27.000 This is not required synchronization with windows. 07:27.000 --> 07:31.000 And this includes wind up position, rendering order, server side decorations. 07:31.000 --> 07:35.000 The wind management protocol allows wind managers to draw whatever decorations they want. 07:35.000 --> 07:41.000 Window cropping can also crop off the client side decorations that GTK is drawn if you want it to. 07:41.000 --> 07:44.000 And this kind of thing, that's rendering state. 07:44.000 --> 07:51.000 And so the core loop of this protocol is demonstrate the state machine. 07:51.000 --> 07:55.000 This is how synchronization works is how we get for imperfection. 07:55.000 --> 08:00.000 So when the wind manager starts up idle, then there will be some new events. 08:00.000 --> 08:01.000 Some new window opens. 08:01.000 --> 08:07.000 A cane binding is driven like a wind manager is registered with the compositor from window across to be maximized, etc. 08:07.000 --> 08:12.000 Then the compositor will send us new information to the wind manager over the wind management protocol. 08:12.000 --> 08:14.000 And wait for the wind manager to reply. 08:14.000 --> 08:16.000 I call it a manage sequence. 08:16.000 --> 08:20.000 And the wind manager is allowed to touch any wind management state during this manage sequence. 08:20.000 --> 08:22.000 And so the compositor will keep running frames. 08:22.000 --> 08:24.000 There's no waiting to render a frame here. 08:24.000 --> 08:28.000 The wind manager will keep running frames while wait for the wind manager to reply. 08:28.000 --> 08:33.000 Then the wind manager will automatically update all the state and wants to update and respond to this change. 08:33.000 --> 08:35.000 And make a managed finish request. 08:35.000 --> 08:40.000 Then the compositor will take this new state, send it to all the windows that have been changed autonomously. 08:40.000 --> 08:44.000 And wait for them to all respond before running any new buffers from these windows. 08:44.000 --> 08:49.000 Then as best as then once all the windows that have been active and configured and committed. 08:49.000 --> 08:53.000 Then the windows all have a new buffer of the right size asked for by the wind manager. 08:53.000 --> 08:55.000 Then we can move on to rendering. 08:55.000 --> 09:01.000 And so again we will send all the new window dimensions to the wind manager. 09:01.000 --> 09:08.000 And we will then wait for the wind manager to then position the windows. 09:08.000 --> 09:12.000 Draw a declarations to the right size to all this work. 09:12.000 --> 09:14.000 And finally, call them in your finisher quest. 09:14.000 --> 09:18.000 And then we display the new state on the frame on the end buffer automatically. 09:18.000 --> 09:21.000 And so this gives us frame perfection. 09:21.000 --> 09:27.000 And synchronization with out requiring a round trip between the wind manager and the wind manager every frame. 09:27.000 --> 09:32.000 There's one little missing piece here that someone may have noticed if they're painting any tension. 09:32.000 --> 09:35.000 On the way land, windows are able to change their dimensions by themselves. 09:35.000 --> 09:37.000 And so we've got like one little shortcut here. 09:37.000 --> 09:42.000 If a window decides, I'm just going to ignore what the composer asks for and render this at a fixed aspect ratio. 09:42.000 --> 09:44.000 And PV does this for example if it's floating mode. 09:44.000 --> 09:48.000 It will just render that the dimensions of the video you're playing. 09:48.000 --> 09:56.000 And so if a little shortcut there that allows the wind manager to respond to windows just randomly changing their own dimensions. 09:56.000 --> 09:59.000 By adjusting the size of the decorations of the position of the windows. 09:59.000 --> 10:03.000 And so this is the really the core idea of the wind management protocol. 10:03.000 --> 10:05.000 This is a pretty simple idea. 10:05.000 --> 10:10.000 In fact, this state machine was already hiding inside river before I implemented the wind management protocol. 10:10.000 --> 10:13.000 This is the common state machine shared by many composers. 10:13.000 --> 10:17.000 And I think formally specifying it allows people to reduce the amount of bugs. 10:17.000 --> 10:20.000 Because early versions of river did not do a very good job of implementing the state machine. 10:20.000 --> 10:24.000 And as I learned more about wind development and got better at making everything perfect. 10:24.000 --> 10:27.000 My design got closer and closer to this ideal. 10:27.000 --> 10:30.000 And now that I've formed, I'm kind of realized that this is an ideal. 10:30.000 --> 10:32.000 I'm kind of training towards. 10:32.000 --> 10:35.000 I've specified the state machine formally in the protocol. 10:35.000 --> 10:38.000 And wow, anyone to implement their own wind manager on top of it. 10:38.000 --> 10:43.000 So let's talk a bit more about the motivation for this whole wind management protocol. 10:43.000 --> 10:48.000 The main goal is just to make wind and wind element is significantly easier. 10:48.000 --> 10:52.000 It takes only 600 lines for me to write the wind manager. 10:52.000 --> 10:53.000 I'm using it right now. 10:53.000 --> 10:57.000 I'm using this protocol to display this frame to you right now of course. 10:57.000 --> 11:00.000 I'm daily driving it myself for a couple months already. 11:00.000 --> 11:03.000 And it only took about 600 lines of a high-level language to write the wind manager. 11:03.000 --> 11:05.000 I'm comfortable daily driving. 11:05.000 --> 11:08.000 It's pretty much as beautiful as what river was doing before. 11:08.000 --> 11:10.000 Which is pretty great, I think. 11:10.000 --> 11:15.000 So you can write wind manager in high-level garbage-like languages without destroying composer latency. 11:15.000 --> 11:18.000 The composer is not waiting on the wind manager to reply every frame. 11:18.000 --> 11:21.000 And so, can winding composers are very latency sensitive programs. 11:21.000 --> 11:25.000 You really don't have a very much time, especially with a high refresh rate monitor to render frames. 11:25.000 --> 11:31.000 Especially if you're delaying your rendering to just make it just in time before the frame deadline. 11:31.000 --> 11:35.000 To maximize or to minimize latency, you really cannot have a garbage collector in your compositor. 11:35.000 --> 11:37.000 It's not going to work out well. 11:37.000 --> 11:41.000 But it's nice to use a garbage collector when you're writing high-level wind management logic. 11:41.000 --> 11:46.000 It's nice to use languages like hastal to specify things in a crazy, functional, high-level way. 11:46.000 --> 11:49.000 And this wind management protocol makes that possible. 11:49.000 --> 11:54.000 It's also just a much better development experience because you don't need to restart your compositor 11:54.000 --> 11:56.000 and lose your whole wail insertion if your wind manager crashes. 11:56.000 --> 11:59.000 Or if you just want to switch to a different wind manager or restart your own wind manager 11:59.000 --> 12:01.000 because you change something that you want to try it out. 12:01.000 --> 12:04.000 Such a much better development experience. 12:04.000 --> 12:07.000 And I just want to promote ecosystem diversity. 12:07.000 --> 12:11.000 I think it's really cool because as many wind managers as we had X wind managers, 12:11.000 --> 12:15.000 there's still a massive discrepancy there because it was much easier to write an X wind manager 12:15.000 --> 12:17.000 than it is to wait a whole wavelength composer as a play server. 12:17.000 --> 12:20.000 And we still have a lot of catching up to do there. 12:20.000 --> 12:22.000 And so that's my long-term goals. 12:22.000 --> 12:24.000 Just going to have a more diverse ecosystem. 12:24.000 --> 12:28.000 And help everyone to write their own wind manager if they want to. 12:28.000 --> 12:32.000 And help build better wind managers on the island. 12:32.000 --> 12:36.000 And not just wind managers really because this protocol should work just as built for discipline 12:36.000 --> 12:37.000 environments really. 12:37.000 --> 12:43.000 It's just a low level abstraction that makes it easier to write wail and software. 12:43.000 --> 12:47.000 And so I hope to see some larger, more ambitious system environment products 12:47.000 --> 12:49.000 should be willing to talk about this protocol. 12:50.000 --> 12:52.000 There are some limitations. 12:52.000 --> 12:55.000 This protocols are tricky to like normal 2D desktop stuff. 12:55.000 --> 12:57.000 It's not going to make work very well for VR. 12:57.000 --> 13:01.000 All coordinates are just 2D coordinates and a flat scene graph. 13:01.000 --> 13:04.000 And so if you're using a VR composer, it's not going to help you really. 13:04.000 --> 13:07.000 If you want wobbly windows, it's not going to help you currently. 13:07.000 --> 13:11.000 I mean, maybe we can figure out some way of doing nice animations and crazy stuff like way 13:11.000 --> 13:12.000 fire down the line. 13:12.000 --> 13:15.000 But right now, you're probably going to have different problems with positive. 13:15.000 --> 13:18.000 So it would be cool where the fire would implement this protocol. 13:18.000 --> 13:20.000 Because then you can have both the best of both worlds. 13:20.000 --> 13:23.000 I'm just not interested in working on wobbly windows myself. 13:23.000 --> 13:26.000 That's not my approach. 13:26.000 --> 13:30.000 Some projects like no more KDE probably want to own their entire development stack. 13:30.000 --> 13:34.000 They've got maximal control, maximal integration between their processes there. 13:34.000 --> 13:36.000 And so if you want to do that, maybe this is not for you. 13:36.000 --> 13:40.000 But not every, not every solar developer has got a time to write an entire 13:40.000 --> 13:43.000 compositor and display server as well as a window manager. 13:43.000 --> 13:47.000 And so I'm usually good option for anyone like that. 13:47.000 --> 13:51.000 And well, is there, this is increased global complexity? 13:51.000 --> 13:52.000 I don't think it does. 13:52.000 --> 13:57.000 There's a new asynchronous round trip involved, which was not there before in river. 13:57.000 --> 14:02.000 But I think, making the specifying thing the state machine clearly has actually made 14:02.000 --> 14:05.000 my clean code cleaner in both the compositor and the window manager. 14:05.000 --> 14:08.000 It's a clearer separation of concerns. 14:08.000 --> 14:13.000 And it's really kind of reduced the bugs I have in both cases. 14:13.000 --> 14:18.000 Because there's less mixing of winter management states and winter management policy inside 14:18.000 --> 14:19.000 the compositor is running the loop. 14:19.000 --> 14:23.000 And trying to do synchronization between clients at the same time is also implementing 14:23.000 --> 14:24.000 winter management logic. 14:24.000 --> 14:25.000 Doesn't work out very well. 14:25.000 --> 14:28.000 So separating out the client synchronization issues and the winter management policy 14:28.000 --> 14:31.000 issues has really made my code a lot better. 14:31.000 --> 14:32.000 Yeah. 14:32.000 --> 14:37.000 So currently, this is the current staffs of the protocol. 14:37.000 --> 14:38.000 It's implemented. 14:38.000 --> 14:40.000 It's been stable for about a month and a half. 14:40.000 --> 14:44.000 I'll be doing, I mean, I've been working on for like two years off and on. 14:44.000 --> 14:45.000 There's a design of this protocol. 14:45.000 --> 14:47.000 I went through several iterations already. 14:47.000 --> 14:52.000 But I'm now confident enough that I'm very easy to clear a stable and we'll not 14:52.000 --> 14:53.000 going to break your winter managers. 14:53.000 --> 14:55.000 Just like links is not break user space. 14:55.000 --> 14:56.000 You're free with not break winter managers. 14:56.000 --> 15:00.000 So if you'll come to full depending on this and writing a winter manager against this 15:00.000 --> 15:04.000 protocol, there's already at least nine winter managers I know of. 15:04.000 --> 15:06.000 There's a list on our work if you like. 15:07.000 --> 15:10.000 That I've been written against this protocol in the last one and a half. 15:10.000 --> 15:13.000 So I think that's pretty crazy to see how many people are using this already. 15:13.000 --> 15:15.000 I'm really excited to see that growth. 15:15.000 --> 15:17.000 And there's lots of cool ideas being tried out. 15:17.000 --> 15:18.000 I mean, it's still very early. 15:18.000 --> 15:20.000 Early days of getting money and they're not very polished yet. 15:20.000 --> 15:21.000 But it's a lot of cool ideas. 15:21.000 --> 15:22.000 I mean, I'll show you some in a minute. 15:22.000 --> 15:24.000 So don't worry. 15:24.000 --> 15:28.000 And we're going to be having a river out of four or at least pretty soon. 15:28.000 --> 15:32.000 My main two dudes left before the release are just writing better documentation. 15:32.000 --> 15:34.000 The protocol itself is already very well specified. 15:34.000 --> 15:37.000 The protocol has is basically just documentation. 15:37.000 --> 15:40.000 But this is documentation aimed at people already familiar with writing 15:40.000 --> 15:43.000 wayland clients and wayland compositors, perhaps. 15:43.000 --> 15:45.000 So it's kind of, it's written like a wayland protocol. 15:45.000 --> 15:48.000 And so it assumes you know about wayland and you know how to write a wayland client 15:48.000 --> 15:50.000 and kind of how these things work already. 15:50.000 --> 15:53.000 And I think if you already know those things, it's a very easy protocol to read 15:53.000 --> 15:55.000 and pretty well specified and clearly specified. 15:55.000 --> 15:59.000 However, we're missing like tutorials for people who are never written anything 15:59.000 --> 16:03.000 wayland related before or maybe only familiar with writing an ex-window manager. 16:03.000 --> 16:06.000 I'd like to have some nice documentation to get these people up to speed before we do 16:06.000 --> 16:07.000 release. 16:07.000 --> 16:10.000 And also maybe have like a documentation viewer that's nice and then reading ex-melfiles 16:10.000 --> 16:12.000 because that kind of sucks. 16:12.000 --> 16:16.000 So I'm going to work on those things and maybe type some new, like last minute 16:16.000 --> 16:17.000 piece of requests. 16:17.000 --> 16:19.000 There's not actually like any bugs reported right now. 16:19.000 --> 16:20.000 I don't think. 16:20.000 --> 16:22.000 Well, there's one thing and you fix that kind of requires to, 16:22.000 --> 16:24.000 to be able to roots work though. 16:24.000 --> 16:26.000 But really it's quite stable already. 16:26.000 --> 16:28.000 The architecture has really proved itself. 16:28.000 --> 16:31.000 And I've learned a lot about writing wayland compositors over the past five or six years. 16:31.000 --> 16:35.000 So it's mostly just documentation in a bit of small features, like loose ends 16:35.000 --> 16:37.000 and tie up before we do it release. 16:37.000 --> 16:38.000 All right. 16:38.000 --> 16:40.000 Here are a links to everything. 16:40.000 --> 16:43.000 You can find me at these website in Macedon. 16:43.000 --> 16:45.000 And their source code is on codeburg, of course. 16:45.000 --> 16:47.000 Codeburg is a great project. 16:47.000 --> 16:50.000 Everyone can get away from your GitHub, use codeburg, or something else open source. 16:50.000 --> 16:51.000 They're not used GitHub. 16:51.000 --> 16:53.000 We've got an IRC channel. 16:53.000 --> 16:56.000 This is the most active worker communications that's sequence right now. 16:56.000 --> 17:00.000 I also made a Zulip recently because I thought maybe not everyone likes 17:00.000 --> 17:01.000 the IRC. 17:01.000 --> 17:05.000 Maybe this is going to help us find a grow faster and get more user users. 17:05.000 --> 17:08.000 But still, IRC is used a lot more than Zulip still. 17:08.000 --> 17:10.000 So it's used a bit dead right now. 17:10.000 --> 17:14.000 But if you don't like IRC and you want to use Zulip, come join us on Zulip and make that thing. 17:14.000 --> 17:18.000 But right now, this IRC is pretty much the way to ask questions about river. 17:18.000 --> 17:19.000 All right. 17:19.000 --> 17:20.000 So demo time. 17:20.000 --> 17:24.000 Let's see if we can like test out some winter managers. 17:24.000 --> 17:29.000 There we go. 17:29.000 --> 17:36.000 So let's see how this works. 17:36.000 --> 17:44.000 Kind of hard to read in the screen. 17:44.000 --> 17:52.000 Here we go. 17:52.000 --> 17:53.000 All right. 17:53.000 --> 17:55.000 So this is a winter manager called KWM. 17:55.000 --> 17:58.000 You can see it's got like a whole SaaS bar at the top. 17:58.000 --> 18:03.000 It's kind of VWM lake. 18:03.000 --> 18:08.000 I forgot my keybiting so it seems. 18:08.000 --> 18:11.000 Yeah. 18:11.000 --> 18:19.000 So, yeah, demos. 18:19.000 --> 18:23.000 I really didn't have any of your focus. 18:23.000 --> 18:39.000 Well, so we can do this differently though. 18:39.000 --> 18:51.000 I'm going to get this out of the screen where I can see what I'm doing. 18:52.000 --> 18:56.000 Yeah, I should probably should have used that. 18:56.000 --> 18:57.000 That would have been smart. 18:57.000 --> 18:58.000 But here we go. 18:58.000 --> 19:00.000 Now we've got KWM with Windows Open. 19:00.000 --> 19:01.000 Now we can just find my mouse. 19:01.000 --> 19:03.000 We can make this full screen. 19:03.000 --> 19:05.000 We can see it even better. 19:05.000 --> 19:07.000 That was it. 19:07.000 --> 19:10.000 Well, luckily, I've got plenty of time. 19:10.000 --> 19:12.000 Girl, I've got five minutes. 19:12.000 --> 19:14.000 Well, ask questions. 19:14.000 --> 19:15.000 Or think of your questions. 19:15.000 --> 19:16.000 Okay. 19:17.000 --> 19:18.000 What the heck is that? 19:18.000 --> 19:21.000 I don't know what you said. 19:21.000 --> 19:23.000 Only one minute manager can run at the same time. 19:23.000 --> 19:24.000 I can't repeat the question. 19:24.000 --> 19:26.000 Of course, that's for God. 19:26.000 --> 19:29.000 The question is, what happens if one of the winter manager runs at once? 19:29.000 --> 19:30.000 Well, that can't happen. 19:30.000 --> 19:32.000 Because if a winter manager is already running, 19:32.000 --> 19:35.000 the composable rejects the next winter manager that tries to start and just stop it. 19:35.000 --> 19:36.000 So, you can't have that. 19:36.000 --> 19:37.000 Another question. 19:37.000 --> 19:39.000 Oh, yeah. 19:39.000 --> 19:43.000 Can the winter manager install, like, traditional, with a service sign? 19:43.000 --> 19:44.000 Yes. 19:44.000 --> 19:46.000 The winter manager can draw a service side decoration. 19:46.000 --> 19:47.000 That's correct. 19:47.000 --> 19:48.000 Question. 19:48.000 --> 19:52.000 How do you deal with, um, uncorporative clients who set in your, 19:52.000 --> 19:56.000 in your state machine, your, if before you commit to use that? 19:56.000 --> 19:57.000 Yes. 19:57.000 --> 19:59.000 You're waiting for the clients to, 19:59.000 --> 20:00.000 Yes. 20:00.000 --> 20:01.000 That's right. 20:01.000 --> 20:04.000 But some clients may do that immediately. 20:04.000 --> 20:05.000 And some might be very slow. 20:05.000 --> 20:07.000 The question is, how you deal with clients. 20:07.000 --> 20:09.000 There are slow to respond with the right dimensions. 20:09.000 --> 20:11.000 The answer is the very short time out in this. 20:11.000 --> 20:13.000 The reason for waiting them is just for making the frame is perfect. 20:13.000 --> 20:14.000 Perfect. 20:14.000 --> 20:15.000 Perfect. 20:15.000 --> 20:17.000 And so I think I've got a hundred milliseconds time on that right now. 20:17.000 --> 20:18.000 Maybe it's 50 milliseconds. 20:18.000 --> 20:19.000 I could maybe make it even less. 20:19.000 --> 20:21.000 But, basically, the client responds to slowly. 20:21.000 --> 20:23.000 That client will just get rendered. 20:23.000 --> 20:25.000 Um, well, it just, you'll just have a frame that's not perfect, 20:25.000 --> 20:27.000 because the client's not been fast enough. 20:27.000 --> 20:29.000 And so that's thing about frame perfection requires all the clients 20:29.000 --> 20:31.000 in the winter manager to be willing to well. 20:31.000 --> 20:34.000 And so clients should respond faster than 100 milliseconds, of course. 20:34.000 --> 20:35.000 But some of them don't. 20:35.000 --> 20:38.000 And then you see one imperfect frame, which is not a very big deal. 20:38.000 --> 20:39.000 Question. 20:39.000 --> 20:42.000 Are you aware of any other composable, 20:42.000 --> 20:44.000 that plans to implement the protocol? 20:44.000 --> 20:48.000 I'm not aware of any other composable that plans to implement the protocol yet. 20:48.000 --> 20:50.000 Um, but maybe someday. 20:50.000 --> 20:52.000 I mean, right now it's kind of my job to make, 20:52.000 --> 20:56.000 demonstrate the protocol's worth implementing and to get collaboration there. 20:56.000 --> 20:57.000 Um, yes. 20:57.000 --> 20:58.000 Question. 20:58.000 --> 20:59.000 Yes. 20:59.000 --> 21:01.000 Is there a portfolio behind the window? 21:01.000 --> 21:02.000 For abandoned windows. 21:02.000 --> 21:03.000 What will we find in this? 21:03.000 --> 21:04.000 Repairing windows. 21:04.000 --> 21:06.000 What do you mean by repairing windows? 21:06.000 --> 21:08.000 That's an excellent time I believe. 21:08.000 --> 21:11.000 So basically, like the control looks, 21:11.000 --> 21:15.000 the dimensions that already get us to the window manager. 21:15.000 --> 21:18.000 And the window manager basically. 21:18.000 --> 21:21.000 So the window manager always has control of dimensions. 21:21.000 --> 21:23.000 And position of the windows. 21:23.000 --> 21:25.000 Is that answer the question? 21:25.000 --> 21:26.000 Yeah. 21:26.000 --> 21:27.000 Okay. 21:27.000 --> 21:28.000 Any other questions? 21:28.000 --> 21:29.000 Questions? 21:29.000 --> 21:30.000 Yeah. 21:30.000 --> 21:34.000 Do you have any plans of pushing that to the regular rules or something like that? 21:34.000 --> 21:35.000 Um, 21:35.000 --> 21:36.000 W roots is a lower level library. 21:36.000 --> 21:38.000 I think it makes sense to have this implemented and the 21:38.000 --> 21:39.000 compositor. 21:39.000 --> 21:41.000 The question is if I have plans to push the window management protocol into 21:41.000 --> 21:44.000 rubble roots and implement it there, rather than the compositor. 21:44.000 --> 21:45.000 Um, not the time. 21:45.000 --> 21:48.000 I want to keep control of it myself, so I can iterate quickly and kind of 21:48.000 --> 21:50.000 not wait on anybody else. 21:50.000 --> 21:51.000 Um, yes. 21:51.000 --> 21:54.000 Um, for a compositor to have like, uh, 21:54.000 --> 21:56.000 dynamic movement for example, 21:56.000 --> 21:58.000 you have this overview. 21:58.000 --> 21:59.000 Mm-hmm. 21:59.000 --> 22:04.000 Would this kind of interaction where you have to ask the window manager for 22:04.000 --> 22:06.000 the position you work well for the automations like that? 22:06.000 --> 22:10.000 Um, so the question is about animations and if the program call supports like 22:10.000 --> 22:12.000 more food animations. 22:12.000 --> 22:14.000 Um, so this is kind of a question. 22:14.000 --> 22:17.000 So I'm presenting it for like moving around a window with your mouse is kind of a similar thing. 22:17.000 --> 22:19.000 That already works perfectly well. 22:19.000 --> 22:21.000 Recycling windows interactively works perfectly well. 22:21.000 --> 22:24.000 You can even resize many windows at once, even that they have window manager 22:24.000 --> 22:25.000 random decorations. 22:25.000 --> 22:27.000 That works for in a frame perfect fashion. 22:27.000 --> 22:28.000 So that works pretty well. 22:28.000 --> 22:30.000 Um, not many people have experienced animations yet though. 22:30.000 --> 22:33.000 So there's still a bit of like new ground to be discovered there. 22:33.000 --> 22:34.000 That's where you want to test. 22:34.000 --> 22:38.000 I'm definitely happy to add new features to the protocol to support these use cases. 22:38.000 --> 22:39.000 Um, question. 22:39.000 --> 22:40.000 Yes. 22:40.000 --> 22:46.000 Do you plan to ensure this more, um, use rate of the DWM that's intertile? 22:46.000 --> 22:48.000 Um, that's for the window manager's this side. 22:48.000 --> 22:52.000 Um, the window manager I showed you briefly K to UM has the questions about if I want to 22:52.000 --> 22:54.000 introduce more different tiling algorithms. 22:54.000 --> 22:57.000 And the answer is that that's probably what this program makes possible. 22:57.000 --> 23:00.000 It makes possible to anyone to write any tiling algorithms as they want. 23:00.000 --> 23:04.000 And so I think the one I showed briefly K to UM has got, um, a great algorithm, 23:04.000 --> 23:07.000 like a side-scrolling algorithm, a master stack, a thing of yellow. 23:07.000 --> 23:10.000 It's got everything W don't give you the WM it has for sure. 23:10.000 --> 23:11.000 And the back question? 23:11.000 --> 23:18.000 The question is if I would submit this protocol to the XT namespace. 23:18.000 --> 23:22.000 Um, yes, I'd consider it, but I think there's some work we've done still to 23:22.000 --> 23:27.000 make the this true design is really addresses more than just my compositors needs. 23:27.000 --> 23:31.000 And that would require, by and from other compositors, um, behind you and 23:31.000 --> 23:32.000 break in the back. 23:32.000 --> 23:36.000 Sorry, if you're in an eighth question, so if you said a garbage collection is on 23:36.000 --> 23:37.000 what's the sole problem for us? 23:37.000 --> 23:38.000 Yes. 23:38.000 --> 23:40.000 I guess it was very dynamic. 23:40.000 --> 23:43.000 You would potentially see I picked up the code. 23:43.000 --> 23:49.000 Um, so I, I, I'm using a, to the question is, can you, can you, can you 23:49.000 --> 23:51.000 wait, it wouldn't matter if it's so slow that it makes you just your 23:51.000 --> 23:52.000 proper environment unusable? 23:52.000 --> 23:54.000 I'm sure you can, but I haven't seen it done yet. 23:54.000 --> 23:57.000 The one I'm using for my daily driving is written in a very slow way. 23:57.000 --> 23:59.000 It's written in a very slow, high level language. 23:59.000 --> 24:01.000 And I've not done any optimization at all. 24:01.000 --> 24:03.000 It's written in the simplest way possible, which is a lot, 24:03.000 --> 24:05.000 repeats a lot of work every time it's a request. 24:05.000 --> 24:11.000 And, exactly, yes, we only send requests to wind a manager when it needs to 24:11.000 --> 24:12.000 make a decision. 24:12.000 --> 24:16.000 There's no writing for every, every, every frame or every input events. 24:16.000 --> 24:19.000 There's not added latency when I'm just typing into my terminal. 24:19.000 --> 24:20.000 Um, yes. 24:20.000 --> 24:21.000 Yes. 24:21.000 --> 24:24.000 You said you only send an event to the wind a manager when something happened. 24:24.000 --> 24:25.000 But the wind a manager is in trigger. 24:25.000 --> 24:27.000 Move wind or whenever it wants to do anything. 24:27.000 --> 24:28.000 Yes. 24:28.000 --> 24:31.000 The wind a manager can submit a, a managed, the, the, the question is, 24:31.000 --> 24:35.000 if the wind a manager can trigger, um, events on its owner core. 24:35.000 --> 24:37.000 For example, if it gets a message over debust or someone clicks on the 24:37.000 --> 24:38.000 stats bar. 24:38.000 --> 24:41.000 The answer is the wind a manager can send a managed dirty request to the 24:41.000 --> 24:42.000 compositor. 24:42.000 --> 24:45.000 It'll tell it to start a new managed sequence next time it's idle. 24:45.000 --> 24:46.000 Um, yes. 24:46.000 --> 24:47.000 Question. 24:47.000 --> 24:50.000 What sense of the way of like lovely windows and animations? 24:50.000 --> 24:52.000 Uh, what stands in the way of that? 24:52.000 --> 24:54.000 Um, the question is what stands in the way, okay, my time's up. 24:54.000 --> 24:55.000 Sorry, everybody. 24:55.000 --> 24:57.000 I'll answer all the rest of your questions in the hallway. 24:57.000 --> 24:58.000 Thank you very much. 24:58.000 --> 24:59.000 Come to my talk. 24:59.000 --> 25:09.000 Thank you.