WEBVTT 00:00.000 --> 00:19.440 Okay, so good afternoon, everyone. Can you hear me at the back there? Good. Okay, I'm Alan Griffiths. 00:19.440 --> 00:27.680 I'm the author of the Maryway Compositor and for money, I work for canonical on their mere 00:27.680 --> 00:37.120 compositor library, on which Maryway is based. I think my wife might be watching, so I'm going 00:37.120 --> 00:44.480 to explain what a window manager is very quickly. There's one of the application presents 00:45.520 --> 00:53.200 its window to the system. Something's got to decide where that window goes and any effects 00:53.280 --> 00:58.800 are going to be applied to that. That's the window manager. So when you have multiple things on your 00:58.800 --> 01:08.080 screen, then it decides where to place it or whether to make it fall screen and position it accordingly. 01:08.080 --> 01:16.160 And some special windows like venues and the like have to respect the boundaries of the screen 01:16.400 --> 01:26.240 and they need positioning appropriately is respect to the parent window. The ex-org 01:28.240 --> 01:35.280 well, the excellent ecosystem makes it very easy to develop window manager separately from 01:35.280 --> 01:39.920 the rest of the system. And it's been around for a long time when people are very used to it. 01:40.240 --> 01:48.320 But as I've been very visible over the last year or so, there's been a change and ex is 01:48.320 --> 01:56.320 becoming replaced by Whale and. Ex-org is just the most popular implementation of ex, 01:56.320 --> 02:06.560 well, actually 11 these days and it's been going for a long time. There are 02:06.560 --> 02:15.760 were in the early days 46 years ago when ex started a number of compositors supporting ex. 02:17.760 --> 02:24.480 And it's done a really good job for a long time. But Whale and has a different paradigm to ex 02:24.480 --> 02:34.640 and this has an impact on window managers. In ex and ex 11, the window manager is a separate process 02:34.720 --> 02:42.640 to the compositor. That means it's very easy to develop an independent window manager 02:42.640 --> 02:48.320 that does things in its own way and has been a lot of innovation around that area. 02:49.840 --> 02:54.560 With Whale and the window management is tightly integrated into the compositor. 02:55.360 --> 03:00.560 So that solves a number of problems to do with synchronization, to do with security, 03:01.280 --> 03:09.120 but it doesn't make it very easy to innovate. He can't just ship a window manager for a Whale 03:09.120 --> 03:15.200 and system. There's a lot of examples of window managers out there. They do things like 03:16.320 --> 03:22.400 tiling the windows or having them floating around the desktop, four screening them. There's 03:22.400 --> 03:27.760 different variations of tiling. There's automatic tiling. There's manual tiling. 03:28.720 --> 03:34.960 The scrolling window managers, there's probably things I haven't even heard of. It's a great 03:34.960 --> 03:43.920 field of innovation and we don't want to lose that opportunity. But what we do with Whale and 03:43.920 --> 03:50.880 the window manager is part of the compositor. You can't just ship it separately and experiment. 03:51.600 --> 03:59.280 So I'm going to pause slightly at a few points here to make sure that people are still 03:59.280 --> 04:02.640 nodding along. I've seen nod already. That's very encouraging. 04:04.720 --> 04:11.680 X11 to Whale and is a change in the architecture. And it's a challenge for the innovation 04:11.680 --> 04:17.520 in window management. Everyone's nodding. There's a hand. 04:17.600 --> 04:20.080 Could you maybe briefly explain what a compositor does? 04:20.080 --> 04:24.480 Okay. A compositor. Sorry, the question is, what's a compositor? 04:26.000 --> 04:33.520 Yes. I'll tell you as well. It takes all of these windows, join them together and put some onto the screen. 04:35.440 --> 04:37.360 Is that a good answer? Thank you. 04:39.760 --> 04:45.360 Well, one approach is just to continue with the architecture that X11 has. 04:45.360 --> 04:51.920 The introduce communications between your compositor and an external process that does all the 04:51.920 --> 04:58.720 window management logic. That would make it easy to make innovations to the window manager. 05:00.480 --> 05:10.160 But it introduces IPC, multiple points of failure. It may introduce, it's only introduces 05:10.240 --> 05:14.960 security concerns. You have issues with synchronization. 05:16.640 --> 05:22.560 There's a talk later on this afternoon by one of the river compositor developers, 05:22.560 --> 05:27.920 because they've implemented a protocol that from the summary does something very much like this. 05:28.720 --> 05:32.960 It's an approach. That's not the approach I'm going to be talking about here. 05:33.200 --> 05:38.720 I'm going to talk about the approach taken by meere. 05:40.720 --> 05:49.920 Meere has a very, has on the design where various design decisions have been isolated. 05:49.920 --> 05:54.160 So the window management is isolated from the rest of the support. 05:54.160 --> 06:00.560 So it's not affected by the details of well and protocol implementations or different options, 06:00.560 --> 06:06.960 graphics hardware. And there's been a number of real-world projects out there, shipping, 06:06.960 --> 06:13.040 and in use that's a based on the Meere compositor. So at the top of my slide, I've got 06:13.040 --> 06:20.000 Ubuntu Frame, which is part of canonical's IoT offering. It's a single application, 06:20.000 --> 06:27.760 Kiosk style window manager. Meere called WM. That's a tiling window manager. 06:28.400 --> 06:34.720 LeMeere, that's tries to do things very cleverly. It works in different modes depending on the hardware 06:34.720 --> 06:41.520 it's running on. So if it's running on a phone, it gives you a phone style single application window. 06:43.360 --> 06:47.760 It's running on a tablet. You can also get side stage. If it's running on the desktop, 06:47.760 --> 06:55.040 you get floating window management. And Meere way is my own hobby project. That's a traditional 06:55.120 --> 07:03.120 floating window manager. So what is Meere? It's a library for building 07:03.120 --> 07:12.480 wind-wailing compositors. It has a lot of defaults in it, or work for most cases, but it allows 07:12.480 --> 07:19.360 a lot of customization. Not only window management, but things like the graphics stack can be plugged 07:19.360 --> 07:27.280 and played. Bit more story about Ubuntu Frame. It's a commercial product from canonical, 07:28.000 --> 07:33.440 and because it uses Meere, we've got some guarantee that Meere is going to continue to receive 07:33.440 --> 07:44.000 support from canonical. It's used in a lot of embedded situations. It's usually paired with Ubuntu 07:44.080 --> 07:51.200 core. It's a snap-based system, which has advantages for some scenarios. 07:54.160 --> 08:00.800 Ubuntu Touch, that was originally a project by canonical, but they pulled out of it about 10 08:00.800 --> 08:06.000 years ago. So there's not been involved for a long time. You'd be ports of running that now. 08:06.000 --> 08:18.000 A community group, and they're using Meere to run their phones. Miracle Miracle WM is a hobby 08:18.000 --> 08:24.800 project with one of my colleagues. Matt Kasark, he likes tiling window managers, and he was working 08:24.800 --> 08:32.720 on Meere, so he built one on Meere because he could. People are using it. I've seen very positive feedback. 08:33.040 --> 08:39.680 It's a tiling window manager. I've already said that. It's a highly configurable, at least 08:39.680 --> 08:46.080 according to its website, and it gives a modern experience much in the style of I-3 and Sway, 08:46.080 --> 08:55.440 but according to Matt, it's better. There's also something very interesting in this context. 08:56.400 --> 09:05.200 Matt is looking at making window management in Miracle WM. It's a PR that I discovered on his 09:07.520 --> 09:16.080 GitHub, introducing APIs that can be called out from in this case WebAssembly plugins. 09:17.680 --> 09:23.120 That's obviously a good way of making things window management, variable. 09:26.320 --> 09:33.200 We're Meere. It's part of the same project as a Buntry Touch Ship canonical, and again, 09:33.200 --> 09:41.280 it's been run without canonical for the last 10 years. It does a lot of wizi things with the graphics 09:41.280 --> 09:50.400 on the screen that Meere doesn't do, like this spread display here. It supports phones, tablets, 09:50.400 --> 10:01.280 and desktop. My project, Meere, why? This is designed to be very flexible and agnostic about 10:01.280 --> 10:08.880 the environment. It's running in. It will support at Wail and Index 11 applications. It's got dynamic 10:08.880 --> 10:16.880 workspaces and support for whatever docs, panels, backgrounds that you're interested in playing with. 10:16.960 --> 10:21.600 This laptop's running Meere way, so I'm very confident that it will work for the length of 10:21.600 --> 10:31.120 a presentation. While I was putting this talk together, I thought, well, how hard would it be 10:31.120 --> 10:39.200 to make window management playable in Meere way? I think it's possible, not sure whether I'm 10:39.280 --> 10:44.160 going to find time to do it, but it's definitely a possible avenue to go with. 10:48.000 --> 10:56.800 And last weekend, I think it was, I discovered that the Buggie developers have also decided that 10:56.800 --> 11:01.440 Meere is useful to them, and has started work on something they're calling Meere Pie, 11:02.240 --> 11:08.480 which is, yes, another Meere composer. Details to be announced in the future. 11:10.160 --> 11:20.880 So, now the pause point. Meere has very flexible window management. It will support a variety 11:20.880 --> 11:26.000 of window management, paradigms, and these have been proven in real-world projects. 11:29.040 --> 11:29.760 Have everyone happy? 11:30.400 --> 11:32.400 Question. 11:43.040 --> 11:48.160 I have not got enough experience of double-year-old routes to comment very much on that. 11:48.640 --> 11:50.000 It's been around a lot longer. 11:57.200 --> 12:02.400 So, let me talk you through the process of building a window manager, 12:03.440 --> 12:07.840 well, building with a composer with Meere and some custom window management. 12:07.840 --> 12:13.360 There's two parts to this. There's building a composer that's pretty trivial, 12:13.440 --> 12:18.640 not much more than hello world, and implementing custom window management, 12:18.640 --> 12:23.280 well, that depends on the window management. It could be trivial. It could be very complicated. 12:25.840 --> 12:33.840 First thing you need is to install the parts of Meere that's needed. On Debian-based systems, 12:33.840 --> 12:40.800 then you need to pull the live-mill development library and the desktop graphics drivers. 12:41.200 --> 12:47.840 Meere has plug-able graphics drivers, and this is a meta-package that falls in all the things 12:47.840 --> 12:54.720 you're likely to want on the desktop. So, it will run with Debian-PMS. It will run on top of a 12:54.720 --> 13:02.160 way than a composer to run on top of an X11 composer. There are also drivers in video. Do you 13:02.160 --> 13:07.440 be put, guys? We've got one sort of running on their live-hybrid Android stack. 13:09.600 --> 13:17.600 It's a look a bit simpler on Fedora and the like, because they've got a simpler and less granular 13:18.320 --> 13:24.000 packaging system. You just need to install the Meere library. On Alpine, 13:24.960 --> 13:35.520 it's APK add Meere dev. I don't know why. You also need to install XKB common shouldn't be necessary 13:35.520 --> 13:44.560 to do that explicitly, but it is. So, building a Meere composer here's a mate file. 13:45.440 --> 13:55.440 You can see it's a C++ project. It uses the Meere library and it's got a main.cpp. 13:58.000 --> 14:04.720 So, this is the entire composer for the simple case. You include a few header files, 14:06.000 --> 14:13.200 you instantiate Meere runner, and then you run it using the minimal window manager. 14:15.200 --> 14:22.160 And if you compile it and run it and run a test program like this, you'll see typically an X11 14:22.160 --> 14:27.760 window appear on your screen with that application running in it. You can run it on a VT and 14:27.760 --> 14:36.240 chase it will take over the whole screen and also work that way. All the normal stuff works when 14:36.240 --> 14:43.440 those will appear. There will be a floating menus pop-ups and the like will be placed correctly. 14:45.520 --> 14:54.320 That whole exercise is on the Meere documentation on read the docs. There's a QR code taking 14:54.320 --> 15:04.720 there if it's of interest. Question. So, earlier in your presentation, you mentioned that X11 has 15:04.720 --> 15:10.560 its composer and its display service, separate entities and in women, it's all the same within 15:11.440 --> 15:18.320 it. Then how does it work when you call an X11 window within women? 15:18.320 --> 15:25.600 Okay. Question is, is such a weirdo X11 application gets supported on Wailand? 15:26.960 --> 15:36.160 So, there is an x-compositer implemented in terms of a Wailand composer underneath it called x-wailand, 15:36.240 --> 15:42.640 and a wide variety of Wailand-based test stops use that to add the X11 support. 15:45.360 --> 15:46.480 Other questions? 15:46.480 --> 15:48.880 Can I go back to the previous slide? 15:48.880 --> 15:54.640 Of course. This is the executing your sample display. Yes? 15:54.640 --> 15:59.200 Does it come with the window declaration by default, and are there a customer in the folder? 15:59.840 --> 16:08.080 These window declarations here from Meere's X11 support are not. This is Meere running on X11. 16:08.080 --> 16:11.920 It just draws a very basic declaration. 16:13.920 --> 16:21.840 Not for this scenario, which is Meere is being an application running on x in a certain way. 16:22.160 --> 16:28.400 Excellent applications on Wailand, we'll talk about in a bit. 16:35.680 --> 16:41.440 I've permitted myself a small digression here, because there's been a lot to talk about 16:41.440 --> 16:44.560 why we should get away from using languages like C++. 16:44.640 --> 16:52.320 There are problems with software development. This is, well, essentially stolen from a herb 16:52.320 --> 17:01.040 software slide from a year or two back. I identify the fact that there are highlighted many 17:01.040 --> 17:07.840 CVEs that are related to language support, and languages could be designed in a way to support it. 17:08.400 --> 17:16.720 That makes up about 40% of the total CVEs. It is a fraction of the whole problem, 17:17.760 --> 17:23.200 and the memory safe languages solve around 70% of those problems. 17:24.240 --> 17:29.920 The figure that's often heard and is often interpreted to say, it solves 70% of the problems. 17:29.920 --> 17:31.920 It's not, it's about a quarter of the problems. 17:32.800 --> 17:48.080 Many of the things can be avoided in modern C++. C-style C++ is not a safe as modern C++, but it's 17:48.080 --> 17:53.920 in the language, it's supported, it's supposed to compile, and that means the language isn't memory safe. 17:54.960 --> 18:01.840 This is the equal C++, although I hope no C++ developer is going to write code like this. 18:02.640 --> 18:09.600 You can create an un-initialized structure. You can access parts to that, which is long. 18:10.800 --> 18:16.080 You can index from a pointer, and get an out of bounds read. That's wrong. 18:17.360 --> 18:23.120 You can free this data structure, and you can continue trying to use it. That's wrong, 18:23.760 --> 18:26.080 and you can try and free it again, which is wrong. 18:26.480 --> 18:36.720 Modern C++ doesn't look like that. We're allocating a structure. We can't, because compile 18:36.720 --> 18:42.240 our complaints, try and use things that are not well. That will guarantee that it's initialized. 18:44.800 --> 18:49.760 For some initialized memory if you've already initialized it, you can't, because there's 18:49.760 --> 18:57.520 compile error, go out of bounds, and you can't even talk about the data, because after the 18:57.520 --> 19:03.600 lifetime the name doesn't exist anymore, and you can compile error, and you can't free it again. 19:05.520 --> 19:11.680 The thing is, we can write modern C++. We don't necessarily do it, but the tools don't 19:11.680 --> 19:16.800 actually make us do it either. There is some tooling around to help, but that's very much 19:16.800 --> 19:23.520 post-compilation, called tooling. There's a lot of them for improvement, but C++ is not a 19:23.520 --> 19:32.640 lost cause. Sorry, back to the main story. I've talked about building the composer 19:33.840 --> 19:41.360 now about customizing the window management. We go back to this hello world code, and highlight 19:41.360 --> 19:46.640 a line here that says, certainly window management policy don't minimal window management. 19:48.640 --> 19:56.240 So what is this here, window, minimal window manager? Is a C++ class, that inherits from 19:56.240 --> 20:03.680 window management policy, and window management policy is the thing that liberal use is for 20:03.680 --> 20:10.560 all its window management. So when a window management decision is needed, it calls that interface, 20:11.520 --> 20:15.840 if you provide an implementation of that interface, it will use your implementation, 20:16.560 --> 20:24.080 and that will manage the windows. In fact, just the composers I've talked about, 20:28.080 --> 20:34.560 Maryway makes use of minimal window manager, extends it with a bit of stuff like what's 20:34.560 --> 20:46.240 space support. Frame also uses minimal window manager. Miracle does its own, and I've not looked 20:46.240 --> 20:50.960 at the library code to find out what it's doing, but it must be doing something along these lines. 20:54.880 --> 21:04.480 So window management policy, it's how Mary's customized and it has essentially two categories 21:04.880 --> 21:12.080 of functions on it. One category of advised functions that say something is happening that you 21:12.080 --> 21:18.880 may be interested in, you don't have to implement those functions, there are default implementations 21:18.880 --> 21:28.560 that do nothing. There are a handle ones that require a decision. Here's a list of the handle 21:28.560 --> 21:37.920 functions, there are things like, well, we're going to put this new window. If the application 21:37.920 --> 21:46.560 is trying to change it, it could be resizing it, it could be changing its state to minimised, 21:46.560 --> 21:54.400 or maximised, or false screen, you have to do something with that. You also get the handle, 21:54.640 --> 22:02.720 input events, keyboard, touch, and pointer. It all pretty much makes sense, and you can use the 22:02.720 --> 22:07.600 three role minimal implementation to avoid having to make decisions if you want to. 22:08.960 --> 22:14.640 The advised ones are things like, when an application first connects, or when screens are connected 22:14.640 --> 22:20.720 and disconnected, or when the focus changes, do not require to do something with that, but you might 22:20.800 --> 22:34.240 want to. This is the example from Maryway. It's inheriting via a template here with the workspace 22:34.240 --> 22:41.840 management strategy. Worked spaces could be applied to other window managers, and it needs to 22:41.840 --> 22:49.280 use the XT workspace extension from Wayland, which is implemented in Maryway. 22:53.120 --> 22:59.440 As a bit more, you can do with customising a American visitor. This whole run with is taking a 22:59.440 --> 23:05.200 list of options. The option we talked about is that window management policy, but there's a few more. 23:05.920 --> 23:15.920 And Maryway does make use of them. It does seem like enabling X11 support, which is just a single option there. 23:15.920 --> 23:20.320 It says it wants to manage the wayland extensions that are available to applications. 23:21.200 --> 23:24.880 That comes down to another difference with X that we talked about in the moment. 23:27.040 --> 23:32.240 But the main thing is to customise a window management, you just have to write an X-clar, 23:32.240 --> 23:40.000 a C++ class that's inheriting from this interface. Are we still good? 23:45.520 --> 23:50.160 Integrating with desktop environments, there's a little more to dealing with a desktop environment 23:50.160 --> 23:56.960 than window management. And like I said, there are things that are different between X and 23:56.960 --> 24:04.560 Wayland. Any application essentially can do anything. So it can move out. In those around, 24:04.560 --> 24:09.200 it can place itself in particular parts of the screen. Wayland doesn't like that. 24:11.200 --> 24:18.720 So there are extensions to Wayland. In particular, there's a privileged extension cord layer shell 24:20.000 --> 24:26.800 that allows applications to place themselves behind everything as a background in front of everything. 24:26.960 --> 24:31.520 As an overlay or lock screen, one edge or another edge of the screen. 24:33.120 --> 24:40.240 And you need to identify who gets these privileges. There's a lot of privileged extensions around 24:40.240 --> 24:45.120 Wayland. They're all optionals. They may or may not be supported by the composer, 24:45.120 --> 24:51.520 and they may or may not be used by the application. Components of a shell really need to access 24:51.600 --> 24:58.160 to a lot of these facilities. But there's stuff like screen scraping. There's virtual input. 24:58.160 --> 25:04.320 There's access to other applications, windows. All of that is bound by default in Wayland 25:04.320 --> 25:11.040 and ordinary applications shouldn't get that stuff. So you have to deal with this. Because 25:11.040 --> 25:16.880 sometimes you need them. This is how a bunch of frame deals with it. It's got some hard coded 25:16.880 --> 25:23.040 permissions in here. It says, if it's the Ubuntu frame on screen keyboard, then it's allowed 25:23.040 --> 25:30.320 to position itself on the screen. It's allowed to respond to requests for input methods. And it's 25:30.320 --> 25:39.600 allowed to generate virtual keyboard events. This is what's fine for the Ubuntu 25:39.920 --> 25:44.160 scenario. We've got a very locked down environment and there's only a few things that are 25:44.160 --> 25:51.360 going to be permissions. For a merry way, I thought that was pretty much too restrictive. 25:52.560 --> 25:59.680 So in merry way, it's configurable. So in the config file, you'll see things that start with shell. 26:00.640 --> 26:07.280 Shell components tell me a merry way that firstly, it's got to run this process. 26:08.080 --> 26:15.200 Secondly, that if this process dies, it needs restarting. And thirdly, it gets access to the 26:15.200 --> 26:22.320 privilege of extensions. So there's a few there. The background, notification, demon, 26:23.280 --> 26:29.600 XFC for panel, the app finder. At the bottom there, there's an example that doesn't have 26:29.600 --> 26:35.600 the shell prefix. That's just an order in the application. That says, if I press control to, 26:35.600 --> 26:44.880 I get a terminal. It works for me. Here's a brief look at some of the code that manages all that. 26:45.840 --> 26:52.080 There's a way-land extensions object that manages the way-land extensions. And you 26:52.080 --> 26:58.960 write code to say, when a process comes along, trying to use, do we advertise this extension or not? 26:59.680 --> 27:04.880 And we make that decision based on whether it's a shell component or not. 27:05.600 --> 27:15.120 And putting that into the configuration, there's a configuration option, also part of the 27:15.120 --> 27:21.280 mail library, that says, put this in as an option. And we'll put that into the config file and 27:21.280 --> 27:31.120 interpret it and call you back with the results. In the run-up to the 2510 release of Ubuntu, 27:31.840 --> 27:40.320 I was testing my way with various desktop, so XFC, E, LXC, Budgie, and Mate. And 27:42.000 --> 27:47.760 configuring my way to run those components. So you can see on there, pretty small, but 27:47.760 --> 27:54.000 recognize them all. They got their top bars, they got their bottom bars, they got their launchers. 27:55.360 --> 28:00.000 It works. It's boring. It's good sort of boring because it is just working. 28:02.080 --> 28:06.480 But this configuration stuff, we need to do a few more things. There's the 28:06.480 --> 28:12.320 merry way config the environment there. That allows you to have configurations for multiple 28:12.320 --> 28:18.000 desktop and stick them in different directories. In this case, setting it to our LXC, 28:18.000 --> 28:22.080 says, look in an LXC sub directory on the config path. 28:22.400 --> 28:35.120 We had a question earlier about the update. No. Back here, about decorations. 28:36.160 --> 28:42.320 Because there's been a lot of debate from two very consistent sides. The service side 28:42.320 --> 28:48.640 decorations, which are very good for keeping everything consistent across your desktop and everything 28:48.720 --> 28:55.600 looking as I, it belongs. That's great. And client side decorations are good from the 28:55.600 --> 29:01.440 application point of view, because you can make use of the extra space in your on your screen. 29:02.960 --> 29:09.280 There's a Wyland extension, XDG decoration that allows applications to say, 29:10.320 --> 29:17.600 what sort of decorations are we going to do? And you get a choice with my way. It will respond 29:17.600 --> 29:23.520 in one of four ways. It will say, you're going to use server side decorations. It can say, 29:23.520 --> 29:28.560 you're going to use client side decorations. Or it can say, do what you like, but I prefer 29:29.760 --> 29:35.360 client side or server side. Question. So for example, if a person were to use a 29:35.360 --> 29:41.680 good to touch where the core goal is to have like the same style consistently across all applications, 29:42.480 --> 29:45.200 in that case, they would always prefer server side decorations. 29:45.920 --> 29:53.920 They would say always. So the question was, if you're writing an environment like a 29:53.920 --> 29:59.280 Ubuntu touch where you want things to look as though they belong, what should you do? You should always 29:59.280 --> 30:04.640 respond with saying, you want server side decorations, then you provide the decorations for yourself. 30:10.240 --> 30:13.840 Applications can just not ask the question and do what they're, 30:13.920 --> 30:20.800 another question. So you say, mirror, they're on the previous slides. You showed that you can run 30:20.800 --> 30:27.680 different desktop environments on your own. Yeah. So the question was, whether on the previous slide, 30:27.680 --> 30:33.120 I was showing that you could run different desktop environments on very way. Yes, you can. Which one 30:33.120 --> 30:40.160 are you running yourself? It's a collection of things that I've put together over the years. So the 30:40.240 --> 30:46.400 one I'm using now has got some components from sway, and it's got some components from, 30:49.280 --> 30:57.040 I'm not sure, XDJ probably. It's a desktop environment in itself. It's a desktop environment. 30:57.040 --> 31:01.440 If you compare the mirror way with a mirror, for example, the Lumilli is more 31:01.520 --> 31:07.200 illumination of a way look closer to where you're using mirror and the desktop environment. 31:08.480 --> 31:14.960 And mirror way is, it doesn't have the desktop environment in itself. 31:15.680 --> 31:24.160 So the question was a comparison between Lumilli and Maryway. So Lumilli is a full desktop environment. 31:24.240 --> 31:32.160 It has its own launches. It has its own top bars. It has its own bottom bars. It has its own 31:32.160 --> 31:38.960 terminal. It has its own background. It's not screen. Maryway is not all of that. 31:39.920 --> 31:45.520 Maryway is just a compositor to which you can attach your own choice of all those elements. 31:46.160 --> 31:50.160 Here we go. 31:50.880 --> 31:56.800 Also used for session start up and closed down. Environment verals allow you to run a script. 31:56.800 --> 32:03.680 That's typically used for setting up and tearing down the system the user is session. 32:06.240 --> 32:14.800 And this was a request to be able to take the team or choice from the system 32:15.680 --> 32:25.440 local. I did it. I don't know why you wouldn't want to take the config from your user session but 32:26.720 --> 32:35.040 it works. So yeah, I think we've really covered it with the questions that were raised already. 32:36.640 --> 32:41.440 You need to keep track of what your components are and give them necessary permissions. 32:42.400 --> 32:47.280 You also need to deal with the user actions that are not directly part of window management. 32:48.720 --> 32:51.600 There are different approaches, frame hard codes, everything, 32:52.320 --> 32:58.720 miracle and Maryway both can use configuration files to let the user set it up and 32:58.720 --> 33:07.920 nearby is going to do something with cake and thick. So deployment. 33:10.960 --> 33:14.400 The good news is that Maryway is available in all good distributions. 33:15.920 --> 33:20.880 So you can just use the example I had on pretty much any system. 33:20.960 --> 33:33.920 There are actually distributions of Maryway and miracle. The fedora LXCute spin is using Maryway. 33:35.760 --> 33:42.240 The fedora miracle window manager spin is using the miracle window manager. 33:42.400 --> 33:50.880 Hello. I've utilized themselves as being. The LXCute spin is a lightweight LXCute background. 33:51.760 --> 33:55.760 It uses Maryway, it's way more than native and it's efficient. 33:57.840 --> 34:00.960 If there's anyone wants to try the download, there it is. 34:03.120 --> 34:04.400 I'll wait for that camera there. 34:04.640 --> 34:13.600 Similarly, the fedora miracle window manager spin. It features a tiling window manager, 34:13.600 --> 34:17.840 very cool. Again, it's a while and native experience. 34:19.680 --> 34:21.040 And another download page. 34:26.800 --> 34:33.120 Some of you will know Neil Gomper. He was involved with both of those spins and very much with the 34:33.120 --> 34:38.080 fedora packaging. He was very impressed with how easy it was to put these things together. 34:38.080 --> 34:40.480 I won't read the quote out. You can read it yourself. 34:42.880 --> 34:48.160 Maryway, I'll see some people from that group down here. According to the website, 34:48.160 --> 34:54.400 that's working on Debian, Alpine, Nick sauce and postmarket OS. So that's available in a few places. 34:54.560 --> 35:03.200 And there's a download page for the ISO. I think there are other options around as well. 35:05.600 --> 35:13.520 But this beauty being nearby is not a problem. Most of it's already in place and there are existing 35:13.600 --> 35:25.280 examples. Any questions? Can you speak up a little? 35:25.280 --> 35:32.160 Yeah. There will be a way to feel like the restrictions in the way of personally 35:32.160 --> 35:37.920 some of these features are a little unique to restricted. Like, but in the first segment, 35:37.920 --> 35:42.160 you're going to need to know you worried about that. So the question was, 35:42.160 --> 35:50.640 as having worked on Maryway, do I find the restrictions in Wailand two restrictive? 35:51.600 --> 35:59.600 And is it going to pause fragmentation? To an extent, there is already some fragmentation. 35:59.600 --> 36:04.960 As I've said, not everyone is implementing all the same Wailand extension protocols. 36:06.960 --> 36:14.400 So, applications and shells have to be careful about what's advertised and how it's implemented 36:14.400 --> 36:20.400 and make choices about what to implement and what not. There's a whole set of core extensions 36:20.400 --> 36:28.480 that any good composite should be implementing. There are some project specific ones. 36:28.480 --> 36:36.560 There are some it's involved in the loss of discussion. But it seemed like a healthy environment where 36:36.560 --> 36:40.560 people acknowledge that there are problems to be solved and try out different solutions. 36:41.920 --> 36:47.120 So maybe there will be problems, maybe there won't, but there's no immediate sign of it. 36:47.120 --> 36:55.200 There was a bit of a fuss last year in the Wailand community because it was getting far too long 36:55.200 --> 37:05.680 to finish some of the discussions. There's another way to just be things. I'm sure it'll be popular 37:05.680 --> 37:13.200 in this audience. You can distribute things as snacks. It's good as a developer. It means you've 37:13.200 --> 37:19.520 got a very direct contact with your end users and you don't have to wait for the really cycle 37:19.520 --> 37:26.320 to ship your code. For me, with Maryway, this is important because I don't want to wait for 37:26.320 --> 37:32.320 the next LTS for anyone to try something. Well, the next one's not too bad. That's only a 37:32.320 --> 37:43.120 few months away, but there are three base snaps in white spread use. I'm going to frame Maryway 37:43.120 --> 37:49.760 and Miracle WM. There are a few others, but they're largely testing of things like what happens 37:49.760 --> 37:58.560 in a strictly confined environment. I'm not going to talk about them here. I've been to frame, 37:58.560 --> 38:09.120 well, here's the snap documentation page of a good-to-fame and Miracle. Question. 38:09.120 --> 38:16.720 I'm not sure if it's already the case, but could you also distribute a desktop environment as a 38:16.720 --> 38:24.160 snack? Maryway is, the question was, can you distribute a desktop environment as a snack? Maryway is 38:24.240 --> 38:35.760 a desktop environment distributed as a snack. So, it's Miracle. I think the UB ports guys have 38:35.760 --> 38:41.040 experimented with putting Lumiri into a snap as well. I've thought seen that as being published yet. 38:42.800 --> 38:50.640 So, Maryway, I've talked about that and QR codes for the various pages. 38:50.640 --> 38:59.520 So, snaps are sensible way to distribute some things, particularly for the IoT scenario it works very well. 39:01.520 --> 39:07.040 But, you know, just to get shipped things shipped quickly, it's also useful for the desktop 39:07.200 --> 39:22.640 style things. So, questions? At the back there. So, the question is about using 39:22.640 --> 39:32.000 matter as a compositor. So, I have no direct experience of using matter as a compositor except 39:32.000 --> 39:38.960 just a consumer of the known desktop environment. What I've heard from people that have is that 39:38.960 --> 39:44.960 they are concerned about its tie-in with the known desktop environment and that it's not really 39:44.960 --> 39:53.120 acknowledging the needs of other desktops. Yes? I'm an embedded developer and for me it's always 39:53.120 --> 39:58.720 important that a way to composite or it makes use of the hardware and they are typically 39:58.720 --> 40:07.440 two areas that are important. One is that applications are able to provide buffers in the native 40:07.440 --> 40:13.360 format that the quantum constraints of a video, for example, it's an MB12 buffer and not, 40:14.560 --> 40:20.320 you know, need to convert it to an RGB buffer. The other is that these buffers can then be placed 40:20.400 --> 40:29.600 on hardware planes as supported by the various processes. How much of that is implemented in 40:29.600 --> 40:39.280 the mirror? Okay, so the question is about embedded development and the support for various 40:39.280 --> 40:47.680 sorts of hardware buffer and the native formats on that hardware. I know that we work, well, 40:47.760 --> 40:52.720 one of the things that mirror has is this plug-able graphics stack and I know that we've done 40:52.720 --> 41:00.240 work with various hardware manufacturers to get their stuff up and running. I don't know the detail 41:00.240 --> 41:06.880 of the work in terms of the buffer formats. So, outside there? 41:06.880 --> 41:26.160 Yes? Yes. Can you speak up a little? 41:26.560 --> 41:37.200 For example, if I want to come down with an animation, is it the responsibility of the mirror 41:37.200 --> 41:44.960 the rhythm and that job for something else? Okay, so near, sorry, the question was, 41:46.960 --> 41:51.440 where does the responsibility for animations in a desktop environment belong? 41:51.520 --> 42:00.880 Near doesn't currently have direct support for any of that, but on top of me are both 42:00.880 --> 42:09.680 Lumieri and Miracle have implemented some animations. It is a known gap in the functionality 42:09.680 --> 42:16.160 of me that we should at least have some default animations and some APIs to make it easier to 42:16.160 --> 42:24.160 develop to your own questions you not have. 42:24.160 --> 42:31.760 Somebody wants to develop an owns when you bump position to万 getting a buys look and participants 42:31.760 --> 42:38.320 when you driving themselves outside them, how would you come here the effort to get into it and 42:38.320 --> 42:42.800 to implement the advantage of that 정도's go need to be compared with 42:42.800 --> 42:47.200 with Q-twelling compositor or W-A-R? 42:47.200 --> 42:50.520 OK, so I'm being, the question is, 42:50.520 --> 42:54.120 how does American Pell compare with the Q-Tweiling 42:54.120 --> 42:57.520 compositor or W-R roots? 42:57.520 --> 43:00.120 I work in the mere project. 43:00.120 --> 43:02.000 So I know what's going on. 43:02.000 --> 43:04.320 Covent, right now, with mere. 43:04.320 --> 43:09.000 So if I compare that with what these other compositor 43:09.000 --> 43:11.480 libraries looked like, the last time I looked at them 43:11.480 --> 43:13.560 and didn't spend very much time on it, 43:13.560 --> 43:17.400 I'm going to have a very biased view. 43:17.400 --> 43:22.160 So I don't really want to say too much on that. 43:22.160 --> 43:25.680 I do know that people have been working with these 43:25.680 --> 43:28.120 and have complained and made nice comments 43:28.120 --> 43:29.800 about me when they've tried it, 43:29.800 --> 43:33.160 but I don't know on what basis those comments are really formed. 43:37.640 --> 43:38.640 Have a back there. 43:38.640 --> 43:41.720 Do you support their X-Can out? 43:41.720 --> 43:45.240 Question is, do I support direct scan out? 43:45.240 --> 43:47.720 No. 43:47.720 --> 43:48.560 Question? 43:48.560 --> 43:51.040 Are there any performance implications 43:51.040 --> 43:53.720 when running one of these old window managers 43:53.720 --> 43:56.520 with meaning instead of an old X-Serva? 43:56.520 --> 43:59.880 Is there any different conjures or advantages? 43:59.880 --> 44:03.760 So the question is, performance compared with mere 44:03.760 --> 44:06.960 and existing X-Serva. 44:07.520 --> 44:11.320 I have not seen any figures on that. 44:11.320 --> 44:15.400 What I can say is that we do work in some constrained environments 44:15.400 --> 44:19.360 and that's never been based as an issue. 44:19.360 --> 44:20.560 Question at the front here? 44:20.560 --> 44:23.680 Why isn't adoption of mere being greater 44:23.680 --> 44:28.120 when you compare to others in which you're trying to do the same thing 44:28.120 --> 44:30.560 because mere has been around for a while? 44:30.560 --> 44:34.160 So the question is, mere has been around for a while. 44:34.160 --> 44:37.120 So what has an adoption being greater compared 44:37.120 --> 44:41.400 with some of the other tools in this space? 44:41.400 --> 44:42.680 You guys can tell me. 44:45.560 --> 44:46.560 I hope the back row. 44:46.560 --> 44:47.840 It's a similar question. 44:47.840 --> 44:52.840 Can we expect to see a little bump or get into the bed 44:52.840 --> 44:55.800 in other top or the railing? 44:55.800 --> 44:58.600 I'm also going to speak, but it's like the door has been 44:58.600 --> 45:00.240 with LX. 45:00.240 --> 45:06.160 So the question is, can we expect the bump to adopt mere 45:06.160 --> 45:08.520 as part of a bump to? 45:08.520 --> 45:11.360 I'm not part of that project. 45:11.360 --> 45:15.480 I know Simon quickly was very keen on using mere, 45:15.480 --> 45:17.800 but I don't think he's got any involvement 45:17.800 --> 45:18.920 in the project anymore. 45:24.080 --> 45:25.080 More questions? 45:25.080 --> 45:40.080 So the question is, will we be implementing the colour 45:40.080 --> 45:43.400 of that presentation, thank you all? 45:43.400 --> 45:48.520 It's on our radar, it's not currently a priority. 45:48.520 --> 45:53.040 So it's going to depend on probably commercial engagements, 45:53.040 --> 45:54.880 whether we spend any time on that. 45:54.880 --> 45:57.280 Certainly, if someone wanted to submit that, 45:57.280 --> 45:59.920 we would be very happy to take that as a poll request. 46:06.000 --> 46:06.440 Any more? 46:09.640 --> 46:11.080 OK, thank you very much. 46:11.320 --> 46:18.400 APPLAUSE 46:26.440 --> 46:27.440 LOL 46:32.640 --> 46:35.680 OK, OK, OK, OK. 46:35.720 --> 46:36.840 OK, OK, OK, OK.