Okay, so good afternoon, everyone. Can you hear me at the back there? Good. Okay, I'm Alan Griffiths.
I'm the author of the Maryway Compositor and for money, I work for canonical on their mere
compositor library, on which Maryway is based. I think my wife might be watching, so I'm going
to explain what a window manager is very quickly. There's one of the application presents
its window to the system. Something's got to decide where that window goes and any effects
are going to be applied to that. That's the window manager. So when you have multiple things on your
screen, then it decides where to place it or whether to make it fall screen and position it accordingly.
And some special windows like venues and the like have to respect the boundaries of the screen
and they need positioning appropriately is respect to the parent window. The ex-org
well, the excellent ecosystem makes it very easy to develop window manager separately from
the rest of the system. And it's been around for a long time when people are very used to it.
But as I've been very visible over the last year or so, there's been a change and ex is
becoming replaced by Whale and. Ex-org is just the most popular implementation of ex,
well, actually 11 these days and it's been going for a long time. There are
were in the early days 46 years ago when ex started a number of compositors supporting ex.
And it's done a really good job for a long time. But Whale and has a different paradigm to ex
and this has an impact on window managers. In ex and ex 11, the window manager is a separate process
to the compositor. That means it's very easy to develop an independent window manager
that does things in its own way and has been a lot of innovation around that area.
With Whale and the window management is tightly integrated into the compositor.
So that solves a number of problems to do with synchronization, to do with security,
but it doesn't make it very easy to innovate. He can't just ship a window manager for a Whale
and system. There's a lot of examples of window managers out there. They do things like
tiling the windows or having them floating around the desktop, four screening them. There's
different variations of tiling. There's automatic tiling. There's manual tiling.
The scrolling window managers, there's probably things I haven't even heard of. It's a great
field of innovation and we don't want to lose that opportunity. But what we do with Whale and
the window manager is part of the compositor. You can't just ship it separately and experiment.
So I'm going to pause slightly at a few points here to make sure that people are still
nodding along. I've seen nod already. That's very encouraging.
X11 to Whale and is a change in the architecture. And it's a challenge for the innovation
in window management. Everyone's nodding. There's a hand.
Could you maybe briefly explain what a compositor does?
Okay. A compositor. Sorry, the question is, what's a compositor?
Yes. I'll tell you as well. It takes all of these windows, join them together and put some onto the screen.
Is that a good answer? Thank you.
Well, one approach is just to continue with the architecture that X11 has.
The introduce communications between your compositor and an external process that does all the
window management logic. That would make it easy to make innovations to the window manager.
But it introduces IPC, multiple points of failure. It may introduce, it's only introduces
security concerns. You have issues with synchronization.
There's a talk later on this afternoon by one of the river compositor developers,
because they've implemented a protocol that from the summary does something very much like this.
It's an approach. That's not the approach I'm going to be talking about here.
I'm going to talk about the approach taken by meere.
Meere has a very, has on the design where various design decisions have been isolated.
So the window management is isolated from the rest of the support.
So it's not affected by the details of well and protocol implementations or different options,
graphics hardware. And there's been a number of real-world projects out there, shipping,
and in use that's a based on the Meere compositor. So at the top of my slide, I've got
Ubuntu Frame, which is part of canonical's IoT offering. It's a single application,
Kiosk style window manager. Meere called WM. That's a tiling window manager.
LeMeere, that's tries to do things very cleverly. It works in different modes depending on the hardware
it's running on. So if it's running on a phone, it gives you a phone style single application window.
It's running on a tablet. You can also get side stage. If it's running on the desktop,
you get floating window management. And Meere way is my own hobby project. That's a traditional
floating window manager. So what is Meere? It's a library for building
wind-wailing compositors. It has a lot of defaults in it, or work for most cases, but it allows
a lot of customization. Not only window management, but things like the graphics stack can be plugged
and played. Bit more story about Ubuntu Frame. It's a commercial product from canonical,
and because it uses Meere, we've got some guarantee that Meere is going to continue to receive
support from canonical. It's used in a lot of embedded situations. It's usually paired with Ubuntu
core. It's a snap-based system, which has advantages for some scenarios.
Ubuntu Touch, that was originally a project by canonical, but they pulled out of it about 10
years ago. So there's not been involved for a long time. You'd be ports of running that now.
A community group, and they're using Meere to run their phones. Miracle Miracle WM is a hobby
project with one of my colleagues. Matt Kasark, he likes tiling window managers, and he was working
on Meere, so he built one on Meere because he could. People are using it. I've seen very positive feedback.
It's a tiling window manager. I've already said that. It's a highly configurable, at least
according to its website, and it gives a modern experience much in the style of I-3 and Sway,
but according to Matt, it's better. There's also something very interesting in this context.
Matt is looking at making window management in Miracle WM. It's a PR that I discovered on his
GitHub, introducing APIs that can be called out from in this case WebAssembly plugins.
That's obviously a good way of making things window management, variable.
We're Meere. It's part of the same project as a Buntry Touch Ship canonical, and again,
it's been run without canonical for the last 10 years. It does a lot of wizi things with the graphics
on the screen that Meere doesn't do, like this spread display here. It supports phones, tablets,
and desktop. My project, Meere, why? This is designed to be very flexible and agnostic about
the environment. It's running in. It will support at Wail and Index 11 applications. It's got dynamic
workspaces and support for whatever docs, panels, backgrounds that you're interested in playing with.
This laptop's running Meere way, so I'm very confident that it will work for the length of
a presentation. While I was putting this talk together, I thought, well, how hard would it be
to make window management playable in Meere way? I think it's possible, not sure whether I'm
going to find time to do it, but it's definitely a possible avenue to go with.
And last weekend, I think it was, I discovered that the Buggie developers have also decided that
Meere is useful to them, and has started work on something they're calling Meere Pie,
which is, yes, another Meere composer. Details to be announced in the future.
So, now the pause point. Meere has very flexible window management. It will support a variety
of window management, paradigms, and these have been proven in real-world projects.
Have everyone happy?
Question.
I have not got enough experience of double-year-old routes to comment very much on that.
It's been around a lot longer.
So, let me talk you through the process of building a window manager,
well, building with a composer with Meere and some custom window management.
There's two parts to this. There's building a composer that's pretty trivial,
not much more than hello world, and implementing custom window management,
well, that depends on the window management. It could be trivial. It could be very complicated.
First thing you need is to install the parts of Meere that's needed. On Debian-based systems,
then you need to pull the live-mill development library and the desktop graphics drivers.
Meere has plug-able graphics drivers, and this is a meta-package that falls in all the things
you're likely to want on the desktop. So, it will run with Debian-PMS. It will run on top of a
way than a composer to run on top of an X11 composer. There are also drivers in video. Do you
be put, guys? We've got one sort of running on their live-hybrid Android stack.
It's a look a bit simpler on Fedora and the like, because they've got a simpler and less granular
packaging system. You just need to install the Meere library. On Alpine,
it's APK add Meere dev. I don't know why. You also need to install XKB common shouldn't be necessary
to do that explicitly, but it is. So, building a Meere composer here's a mate file.
You can see it's a C++ project. It uses the Meere library and it's got a main.cpp.
So, this is the entire composer for the simple case. You include a few header files,
you instantiate Meere runner, and then you run it using the minimal window manager.
And if you compile it and run it and run a test program like this, you'll see typically an X11
window appear on your screen with that application running in it. You can run it on a VT and
chase it will take over the whole screen and also work that way. All the normal stuff works when
those will appear. There will be a floating menus pop-ups and the like will be placed correctly.
That whole exercise is on the Meere documentation on read the docs. There's a QR code taking
there if it's of interest. Question. So, earlier in your presentation, you mentioned that X11 has
its composer and its display service, separate entities and in women, it's all the same within
it. Then how does it work when you call an X11 window within women?
Okay. Question is, is such a weirdo X11 application gets supported on Wailand?
So, there is an x-compositer implemented in terms of a Wailand composer underneath it called x-wailand,
and a wide variety of Wailand-based test stops use that to add the X11 support.
Other questions?
Can I go back to the previous slide?
Of course. This is the executing your sample display. Yes?
Does it come with the window declaration by default, and are there a customer in the folder?
These window declarations here from Meere's X11 support are not. This is Meere running on X11.
It just draws a very basic declaration.
Not for this scenario, which is Meere is being an application running on x in a certain way.
Excellent applications on Wailand, we'll talk about in a bit.
I've permitted myself a small digression here, because there's been a lot to talk about
why we should get away from using languages like C++.
There are problems with software development. This is, well, essentially stolen from a herb
software slide from a year or two back. I identify the fact that there are highlighted many
CVEs that are related to language support, and languages could be designed in a way to support it.
That makes up about 40% of the total CVEs. It is a fraction of the whole problem,
and the memory safe languages solve around 70% of those problems.
The figure that's often heard and is often interpreted to say, it solves 70% of the problems.
It's not, it's about a quarter of the problems.
Many of the things can be avoided in modern C++. C-style C++ is not a safe as modern C++, but it's
in the language, it's supported, it's supposed to compile, and that means the language isn't memory safe.
This is the equal C++, although I hope no C++ developer is going to write code like this.
You can create an un-initialized structure. You can access parts to that, which is long.
You can index from a pointer, and get an out of bounds read. That's wrong.
You can free this data structure, and you can continue trying to use it. That's wrong,
and you can try and free it again, which is wrong.
Modern C++ doesn't look like that. We're allocating a structure. We can't, because compile
our complaints, try and use things that are not well. That will guarantee that it's initialized.
For some initialized memory if you've already initialized it, you can't, because there's
compile error, go out of bounds, and you can't even talk about the data, because after the
lifetime the name doesn't exist anymore, and you can compile error, and you can't free it again.
The thing is, we can write modern C++. We don't necessarily do it, but the tools don't
actually make us do it either. There is some tooling around to help, but that's very much
post-compilation, called tooling. There's a lot of them for improvement, but C++ is not a
lost cause. Sorry, back to the main story. I've talked about building the composer
now about customizing the window management. We go back to this hello world code, and highlight
a line here that says, certainly window management policy don't minimal window management.
So what is this here, window, minimal window manager? Is a C++ class, that inherits from
window management policy, and window management policy is the thing that liberal use is for
all its window management. So when a window management decision is needed, it calls that interface,
if you provide an implementation of that interface, it will use your implementation,
and that will manage the windows. In fact, just the composers I've talked about,
Maryway makes use of minimal window manager, extends it with a bit of stuff like what's
space support. Frame also uses minimal window manager. Miracle does its own, and I've not looked
at the library code to find out what it's doing, but it must be doing something along these lines.
So window management policy, it's how Mary's customized and it has essentially two categories
of functions on it. One category of advised functions that say something is happening that you
may be interested in, you don't have to implement those functions, there are default implementations
that do nothing. There are a handle ones that require a decision. Here's a list of the handle
functions, there are things like, well, we're going to put this new window. If the application
is trying to change it, it could be resizing it, it could be changing its state to minimised,
or maximised, or false screen, you have to do something with that. You also get the handle,
input events, keyboard, touch, and pointer. It all pretty much makes sense, and you can use the
three role minimal implementation to avoid having to make decisions if you want to.
The advised ones are things like, when an application first connects, or when screens are connected
and disconnected, or when the focus changes, do not require to do something with that, but you might
want to. This is the example from Maryway. It's inheriting via a template here with the workspace
management strategy. Worked spaces could be applied to other window managers, and it needs to
use the XT workspace extension from Wayland, which is implemented in Maryway.
As a bit more, you can do with customising a American visitor. This whole run with is taking a
list of options. The option we talked about is that window management policy, but there's a few more.
And Maryway does make use of them. It does seem like enabling X11 support, which is just a single option there.
It says it wants to manage the wayland extensions that are available to applications.
That comes down to another difference with X that we talked about in the moment.
But the main thing is to customise a window management, you just have to write an X-clar,
a C++ class that's inheriting from this interface. Are we still good?
Integrating with desktop environments, there's a little more to dealing with a desktop environment
than window management. And like I said, there are things that are different between X and
Wayland. Any application essentially can do anything. So it can move out. In those around,
it can place itself in particular parts of the screen. Wayland doesn't like that.
So there are extensions to Wayland. In particular, there's a privileged extension cord layer shell
that allows applications to place themselves behind everything as a background in front of everything.
As an overlay or lock screen, one edge or another edge of the screen.
And you need to identify who gets these privileges. There's a lot of privileged extensions around
Wayland. They're all optionals. They may or may not be supported by the composer,
and they may or may not be used by the application. Components of a shell really need to access
to a lot of these facilities. But there's stuff like screen scraping. There's virtual input.
There's access to other applications, windows. All of that is bound by default in Wayland
and ordinary applications shouldn't get that stuff. So you have to deal with this. Because
sometimes you need them. This is how a bunch of frame deals with it. It's got some hard coded
permissions in here. It says, if it's the Ubuntu frame on screen keyboard, then it's allowed
to position itself on the screen. It's allowed to respond to requests for input methods. And it's
allowed to generate virtual keyboard events. This is what's fine for the Ubuntu
scenario. We've got a very locked down environment and there's only a few things that are
going to be permissions. For a merry way, I thought that was pretty much too restrictive.
So in merry way, it's configurable. So in the config file, you'll see things that start with shell.
Shell components tell me a merry way that firstly, it's got to run this process.
Secondly, that if this process dies, it needs restarting. And thirdly, it gets access to the
privilege of extensions. So there's a few there. The background, notification, demon,
XFC for panel, the app finder. At the bottom there, there's an example that doesn't have
the shell prefix. That's just an order in the application. That says, if I press control to,
I get a terminal. It works for me. Here's a brief look at some of the code that manages all that.
There's a way-land extensions object that manages the way-land extensions. And you
write code to say, when a process comes along, trying to use, do we advertise this extension or not?
And we make that decision based on whether it's a shell component or not.
And putting that into the configuration, there's a configuration option, also part of the
mail library, that says, put this in as an option. And we'll put that into the config file and
interpret it and call you back with the results. In the run-up to the 2510 release of Ubuntu,
I was testing my way with various desktop, so XFC, E, LXC, Budgie, and Mate. And
configuring my way to run those components. So you can see on there, pretty small, but
recognize them all. They got their top bars, they got their bottom bars, they got their launchers.
It works. It's boring. It's good sort of boring because it is just working.
But this configuration stuff, we need to do a few more things. There's the
merry way config the environment there. That allows you to have configurations for multiple
desktop and stick them in different directories. In this case, setting it to our LXC,
says, look in an LXC sub directory on the config path.
We had a question earlier about the update. No. Back here, about decorations.
Because there's been a lot of debate from two very consistent sides. The service side
decorations, which are very good for keeping everything consistent across your desktop and everything
looking as I, it belongs. That's great. And client side decorations are good from the
application point of view, because you can make use of the extra space in your on your screen.
There's a Wyland extension, XDG decoration that allows applications to say,
what sort of decorations are we going to do? And you get a choice with my way. It will respond
in one of four ways. It will say, you're going to use server side decorations. It can say,
you're going to use client side decorations. Or it can say, do what you like, but I prefer
client side or server side. Question. So for example, if a person were to use a
good to touch where the core goal is to have like the same style consistently across all applications,
in that case, they would always prefer server side decorations.
They would say always. So the question was, if you're writing an environment like a
Ubuntu touch where you want things to look as though they belong, what should you do? You should always
respond with saying, you want server side decorations, then you provide the decorations for yourself.
Applications can just not ask the question and do what they're,
another question. So you say, mirror, they're on the previous slides. You showed that you can run
different desktop environments on your own. Yeah. So the question was, whether on the previous slide,
I was showing that you could run different desktop environments on very way. Yes, you can. Which one
are you running yourself? It's a collection of things that I've put together over the years. So the
one I'm using now has got some components from sway, and it's got some components from,
I'm not sure, XDJ probably. It's a desktop environment in itself. It's a desktop environment.
If you compare the mirror way with a mirror, for example, the Lumilli is more
illumination of a way look closer to where you're using mirror and the desktop environment.
And mirror way is, it doesn't have the desktop environment in itself.
So the question was a comparison between Lumilli and Maryway. So Lumilli is a full desktop environment.
It has its own launches. It has its own top bars. It has its own bottom bars. It has its own
terminal. It has its own background. It's not screen. Maryway is not all of that.
Maryway is just a compositor to which you can attach your own choice of all those elements.
Here we go.
Also used for session start up and closed down. Environment verals allow you to run a script.
That's typically used for setting up and tearing down the system the user is session.
And this was a request to be able to take the team or choice from the system
local. I did it. I don't know why you wouldn't want to take the config from your user session but
it works. So yeah, I think we've really covered it with the questions that were raised already.
You need to keep track of what your components are and give them necessary permissions.
You also need to deal with the user actions that are not directly part of window management.
There are different approaches, frame hard codes, everything,
miracle and Maryway both can use configuration files to let the user set it up and
nearby is going to do something with cake and thick. So deployment.
The good news is that Maryway is available in all good distributions.
So you can just use the example I had on pretty much any system.
There are actually distributions of Maryway and miracle. The fedora LXCute spin is using Maryway.
The fedora miracle window manager spin is using the miracle window manager.
Hello. I've utilized themselves as being. The LXCute spin is a lightweight LXCute background.
It uses Maryway, it's way more than native and it's efficient.
If there's anyone wants to try the download, there it is.
I'll wait for that camera there.
Similarly, the fedora miracle window manager spin. It features a tiling window manager,
very cool. Again, it's a while and native experience.
And another download page.
Some of you will know Neil Gomper. He was involved with both of those spins and very much with the
fedora packaging. He was very impressed with how easy it was to put these things together.
I won't read the quote out. You can read it yourself.
Maryway, I'll see some people from that group down here. According to the website,
that's working on Debian, Alpine, Nick sauce and postmarket OS. So that's available in a few places.
And there's a download page for the ISO. I think there are other options around as well.
But this beauty being nearby is not a problem. Most of it's already in place and there are existing
examples. Any questions? Can you speak up a little?
Yeah. There will be a way to feel like the restrictions in the way of personally
some of these features are a little unique to restricted. Like, but in the first segment,
you're going to need to know you worried about that. So the question was,
as having worked on Maryway, do I find the restrictions in Wailand two restrictive?
And is it going to pause fragmentation? To an extent, there is already some fragmentation.
As I've said, not everyone is implementing all the same Wailand extension protocols.
So, applications and shells have to be careful about what's advertised and how it's implemented
and make choices about what to implement and what not. There's a whole set of core extensions
that any good composite should be implementing. There are some project specific ones.
There are some it's involved in the loss of discussion. But it seemed like a healthy environment where
people acknowledge that there are problems to be solved and try out different solutions.
So maybe there will be problems, maybe there won't, but there's no immediate sign of it.
There was a bit of a fuss last year in the Wailand community because it was getting far too long
to finish some of the discussions. There's another way to just be things. I'm sure it'll be popular
in this audience. You can distribute things as snacks. It's good as a developer. It means you've
got a very direct contact with your end users and you don't have to wait for the really cycle
to ship your code. For me, with Maryway, this is important because I don't want to wait for
the next LTS for anyone to try something. Well, the next one's not too bad. That's only a
few months away, but there are three base snaps in white spread use. I'm going to frame Maryway
and Miracle WM. There are a few others, but they're largely testing of things like what happens
in a strictly confined environment. I'm not going to talk about them here. I've been to frame,
well, here's the snap documentation page of a good-to-fame and Miracle. Question.
I'm not sure if it's already the case, but could you also distribute a desktop environment as a
snack? Maryway is, the question was, can you distribute a desktop environment as a snack? Maryway is
a desktop environment distributed as a snack. So, it's Miracle. I think the UB ports guys have
experimented with putting Lumiri into a snap as well. I've thought seen that as being published yet.
So, Maryway, I've talked about that and QR codes for the various pages.
So, snaps are sensible way to distribute some things, particularly for the IoT scenario it works very well.
But, you know, just to get shipped things shipped quickly, it's also useful for the desktop
style things. So, questions? At the back there. So, the question is about using
matter as a compositor. So, I have no direct experience of using matter as a compositor except
just a consumer of the known desktop environment. What I've heard from people that have is that
they are concerned about its tie-in with the known desktop environment and that it's not really
acknowledging the needs of other desktops. Yes? I'm an embedded developer and for me it's always
important that a way to composite or it makes use of the hardware and they are typically
two areas that are important. One is that applications are able to provide buffers in the native
format that the quantum constraints of a video, for example, it's an MB12 buffer and not,
you know, need to convert it to an RGB buffer. The other is that these buffers can then be placed
on hardware planes as supported by the various processes. How much of that is implemented in
the mirror? Okay, so the question is about embedded development and the support for various
sorts of hardware buffer and the native formats on that hardware. I know that we work, well,
one of the things that mirror has is this plug-able graphics stack and I know that we've done
work with various hardware manufacturers to get their stuff up and running. I don't know the detail
of the work in terms of the buffer formats. So, outside there?
Yes? Yes. Can you speak up a little?
For example, if I want to come down with an animation, is it the responsibility of the mirror
the rhythm and that job for something else? Okay, so near, sorry, the question was,
where does the responsibility for animations in a desktop environment belong?
Near doesn't currently have direct support for any of that, but on top of me are both
Lumieri and Miracle have implemented some animations. It is a known gap in the functionality
of me that we should at least have some default animations and some APIs to make it easier to
develop to your own questions you not have.
Somebody wants to develop an owns when you bump position to万 getting a buys look and participants
when you driving themselves outside them, how would you come here the effort to get into it and
to implement the advantage of that 정도's go need to be compared with
with Q-twelling compositor or W-A-R?
OK, so I'm being, the question is,
how does American Pell compare with the Q-Tweiling
compositor or W-R roots?
I work in the mere project.
So I know what's going on.
Covent, right now, with mere.
So if I compare that with what these other compositor
libraries looked like, the last time I looked at them
and didn't spend very much time on it,
I'm going to have a very biased view.
So I don't really want to say too much on that.
I do know that people have been working with these
and have complained and made nice comments
about me when they've tried it,
but I don't know on what basis those comments are really formed.
Have a back there.
Do you support their X-Can out?
Question is, do I support direct scan out?
No.
Question?
Are there any performance implications
when running one of these old window managers
with meaning instead of an old X-Serva?
Is there any different conjures or advantages?
So the question is, performance compared with mere
and existing X-Serva.
I have not seen any figures on that.
What I can say is that we do work in some constrained environments
and that's never been based as an issue.
Question at the front here?
Why isn't adoption of mere being greater
when you compare to others in which you're trying to do the same thing
because mere has been around for a while?
So the question is, mere has been around for a while.
So what has an adoption being greater compared
with some of the other tools in this space?
You guys can tell me.
I hope the back row.
It's a similar question.
Can we expect to see a little bump or get into the bed
in other top or the railing?
I'm also going to speak, but it's like the door has been
with LX.
So the question is, can we expect the bump to adopt mere
as part of a bump to?
I'm not part of that project.
I know Simon quickly was very keen on using mere,
but I don't think he's got any involvement
in the project anymore.
More questions?
So the question is, will we be implementing the colour
of that presentation, thank you all?
It's on our radar, it's not currently a priority.
So it's going to depend on probably commercial engagements,
whether we spend any time on that.
Certainly, if someone wanted to submit that,
we would be very happy to take that as a poll request.
Any more?
OK, thank you very much.
APPLAUSE
LOL
OK, OK, OK, OK.