 And we already had, like, I think it was mentioned in two or three talks already, this Academy promo writes about Weyland, we developers talk about Weyland, but Weyland is a very... It can mean different things depending on the context. And with this talk I wanted to look at not all, I don't claim exhaustiveness, but some of the meanings that the term Weyland can have. But first things first, and this is my first Academy, my first real Academy, so quick, who am I? I'm David, one of the Davids. I am a KDE developer, I joined KDE in 2019, currently I work at Plus Systems with the other David that had a talk yesterday. And I don't know how it happened, like, when I joined Plus Systems in 2020, I never did, like, Weyland stuff in Plasma, but somehow David gave me tasks and somehow I'm doing no Weyland development on Plasma, I don't know how it happened. And the real kind of reason I thought of this talk, I also read comments under news articles and on phoronics, on Reddit, and people write about Weyland, I think you're not trying, you're not, what you're writing is not correct, that's not how it works, so that's maybe the real reason for this talk. So some things that you are guaranteed to read there are like, yeah, Weyland doesn't implement something, like, it's missing this feature from X, most famously probably, I can't position my application absolutely on the screen or whatever. Weyland is also a display server like the X server was, or the most recent one I read that your application will need to support three different Weyland implementations and need to have code for everyone of those compositors, like if you run on Plasma or GNOME or with Sway, yeah, let's start with the first meaning of Weyland. First, Weyland is of course a project which develops Weyland and it's also a community. Here is a screenshot of the Weyland group on the free desktop and we can see there are some projects there and there's an IRC channel on OFTC, there's a mailing list called Weyland Devil and there of course also belong to the Weyland community, all the other Weyland developers working in other communities like the MATA developers, GNOME, the GTK developers, developing the GTK backend and so on. And of course, we are also part of the Weyland community with Plasma developers and Weyland compositor and our apps. So Weyland is about how we show things on the screen, how can an app get its UI on the screen instead of using X. And to do this, applications need to talk to each other. We have a special application called the compositor that shows things on screen and the applications talk to it. And in order for the applications to talk to each other, there needs to be a great way how to communicate. Otherwise, if they don't know how to talk to each other, it doesn't work. So Weyland is a Viya protocol like Ibus. It defines a syntax of bytes that the two applications send to each other. And yeah, it's an object oriented protocol. It means like each message, the applications send to each other identify an object and then a method on that object. We say it's a request if the application is sending the method and we call it an event if the compositor does it. But it doesn't matter. Just that it's a defined way of sending bytes across sockets to each other. But that's only the syntax. If we only have syntax, we can't do anything yet. So we also need semantics. So Weyland is also a protocol. It's the Weyland repository contains a core protocol. And with that, you can already do very much. You can show things on screen. On the right of the bullet point, I just added some Weyland debug output so it doesn't look that empty. But if you're interested, you can look it up. You can do input like mouse. The compositor sends you when you move your mouse. Or if you press the key on the keyboard. And that's very good because otherwise the applications would know that you did something, right? And it also can do clipboard and drag and drop. It's already in the core protocol. And I think that's one thing I read somewhere that somebody claimed Weyland doesn't have drag and drop or clipboard support. And I don't know where that came from because on Plasma, you can just, on Plasma Weyland, you can use your clipboard and drag and drop things. So, and Weyland repository contains even more things because Weyland is also a library and not only a protocol. There are actually two libraries, LibWeyland server and LibWeyland client. One for writing your compositor and one for writing your client. It already has a compiled version with C bindings of the protocol included. It handles all the converting your request to this binary format for sending it across the socket. And it also contains some utils for writing a server and a client like handling different queues for different objects where the requests and events are handled. It has some event support for your compositor and also how, and it has facilities to integrate it into a custom event like queues event loop. There's also a third library, LibWeyland cursor, which handles basically your X11 cursor themes, but you get like Weyland images, Weyland objects out that you can then interact with and send to your compositor to show a nice cursor on the screen. But there are even more protocols like the core protocol. It doesn't include every functionality that people then realized later that they wanted. So we have the core protocol, which we already talked about. And then we have a thing called Weyland protocols, which are these additional protocols that are like extensions to the core protocol. And Aleish will talk about it, how you create one and how people agree on that. But some interesting things of the additional protocols are XZG shell, which we use for window management, XZG activation, which we use to activate a window of another process. Tablet input is one of these protocols, or a DMA buff, so we can show things and images on screen more efficiently. And finally, we also have custom protocols in Plasma. Also, Nome has their custom protocols like that are used by our components and are not intended for your general application, like Plasma shell uses custom protocols to communicate with Quinn, to place panels, to manage your screens, and so on and so forth. But if later people think it can be useful to other applications, we can also upstream them instead of creating new ones, of course, in Weyland protocols. Some examples are layer shell, which came from WR routes, and we started using that in Plasma, and it's currently being in process of being standardized. And for example, idle notify 2, which came from us as implementation of K idle time on Weyland, and it tells you when the user is not using the computer and people thought that it is useful for your general application. So there's also, it even wasn't even proposed by us. Simon there from WR routes proposed it to standardize the protocol upstream, so it's quite cool. Now we can look at this beautiful picture and take a sip of water. So doing this talk and thinking about what to talk about, I had a realization that maybe in the end I was wrong when reading and being angry reading all these comments, because what the user sees is if they look into the session in STDM, it says Plasma X11 and Plasma Weyland. So for the user, it doesn't matter everything I just talked about. Weyland is what they see. It's the entire suit of implementations and interactions between them. It's Plasma, it's Quinn, it's a cute Weyland client, it's GDK Weyland, it's some native Weyland and all the interactions between them, and if something goes wrong, Weyland is at fault and I can't be angry about it. I think nobody can because we don't expect our users to be that technical. In an ideal world, we wouldn't have this switcher at all, like there would just be Plasma and the underlying technology should not matter to the user, but certainly we are in there. But I think when reading these comments, I shouldn't be angry, but maybe I should be a little bit angry. Because it's always a matter of how you phrase it, right? But if someone is angry, then there's a problem that we need to solve and it's our task to make Weyland as good and even better than the X session. And I think that it's kind of a conclusion already of my talk that we have to keep that in mind and with that, I want to revisit some two of the things I showed in the beginning of these comments that I read. So the one that applications need to support three different implementations, like one or even more for every compositor. I think that's not true because first the protocols are standardized and most, so everybody has to implement the core protocol. It's standard. The additional protocols are standard and most of them are implemented by most compositors. Mine, Modulu, some things. And all the implementations like Qrin, Matter, Qt, GTK, they try to follow the standard as it's written. And if a developer discovers there's divergence in implementation and it sometimes can cause bugs because the events come in different orders or because it's not defined in which way to send them, then people go to the IRC channel or to the GitLab file issue and then people talk, discuss and we find a conclusion what it should be, the correct thing to do. And so we reduce this need for, there's no need because everybody tries to do it the best way there is and correct ambiguities. Also, I think it was with a screen sharing or something that the people said, or for screenshots that you need to support the three different ways. But I think in the future, or in general, it's also not true because if somebody or two different people have similar custom protocols to a thing, then there will be a process and people try to agree on a common one and upstream that. Or even maybe valent is not the correct place for the protocol. Like maybe it's better suited to the pedestal part like screenshots or screen sharing. And of course we use Qt as a toolkit and that also reduces the need to have some of these. Like when I said not every compositor implements every protocol, for example XDG decoration is the most famous one and so if you use server side or client side decorations and Qt handles that for you and if you're writing a native app for some reason, like valent native, there's lip decor which handles that for you so you don't need to care if your compositor implements the protocol or not. The second thing is valent doesn't support X, Y, and C like valent in the general sense and that can of course be true but it's not like we say we want to have your session be pro. Your use case is not useful but it will not be that the valent developers will say, yeah, you can't do that. Let's do it like you say. We want to understand first the use case because it's maybe possible in a different kind of way or you can give some kind of more data to the compositor so it can fulfill your need so it's not like blindly porting the X protocol to valent protocol and then having the same thing again but understanding the use case and finding a good solution for the missing use case and then we can create a custom protocol if it's just something that we're missing maybe between Plasma and Quinn or it's for every application we can create a standard protocol and if it's a problem people will have out from other communities or maybe again maybe a portal is the correct place but people will try to find a solution if there's really a problem. Then we can implement it in Qtvalent client, in Quinn, in Plasma, wherever maybe some a bit of custom code in the app and then everyone is happy and that's a really nice thing and now without break it's not a late turn and he will talk about us how you do valent protocols.