 Good morning everyone, so I'm with them, I'm working at Enioka and have sponsored some of my time to make this presentation, so that's why you will see them, the branding here. Anyway, so I'm here to speak to you about the way on goal status update for 2020 and how it's been going since it's been elected in 2019, last year at Lycea Academy. A little bit of myself, I've been a KD contributor since last year and I've been working up my contribution ever since and now I've been spending a lot of my time on well on stuff. So the goal, the goal, yeah, so the goal was to, that was proposed by FANIS, was basically to advance KD well on support, well on support in KDE has been a long-going effort, spearheaded in particular by Martin Grasling and K-Win developers and some others, and FANIS proposed this goal to push it further again to make it so that in the end, we should be able to use well on. But the goal, the end goal of this goal is to have a decent enough well on the session with KD software. So it's entitled to that end, we need to win over more users. Right now, well on is not completely stable and not for everyone, but if we can manage to gradually seduce more users, we can have them have more bug reports and bug reports inform the developers so that we can make progress and gather more contribution. And why do we do this anyway? Why does well on entails? Well, most of you must know, but I'll just insist a little more. Well on is adding more security of our graphical interfaces over X, the venerable server X, that has not a very strong security model, whereas well on tries to restrict everything, the applications and the GUI have access to what they need to only. And well on is also this feature that it can make pixel perfection. By that, we mean that it means that we'll be able to refresh the screen with the content when it's ready and only when it's ready without tearing and such artifacts that have played the graphical Linux GUIs for a long time. And well on also allows to have dramatic architecture improvements in separation of concerns so that we can create new things that couldn't be possible with X. So over X, we can have new features. But with well on, we have also more complexity to paraphrase someone with great power comes great responsibility. And here, the responsibility and the power rest on to the lower on the stack up the stack, I mean above the we don't have a X server anymore to handle things. So now it's a compositor that does these things a lot more of what X used to do. In Plasma and in Plasma, it's Queen. So the goal also does not restrict itself to being on KD software. Of course, it's really important for KD software and projects, Plasma and applications. But also on mobile, we have some applications. So that we can reuse well on the sessions also on mobile devices for Plasma mobile. And also upstream because well on is not completely stable and it's still evolving. So we need to have say our interaction within the border community. We have some subjects that need to go further. We need to push our needs and learn and work together to ensure that well on stays a nice platform with good standards and shared protocols. And a very important option in our house is of course QT. So we try to be good with Qt and Qt well on in particular to report bugs and participate wherever we can. And it's one of the scope of our goal. So far, the community has been involved is mainly the Queen developers. Many within our small group of people of about six these days. And a lot of contribution have been come from smaller divers contribute. A lot of contributions have come from smaller contributors punctually of all the time also. So we want to I want to thank them also, but they didn't have an involvement direct involvement within the group. I think the goal, which is great also that things go by themselves and involve by themselves. And just to I'm going to make a small recap of what progress we made and try to convey how we did nice progress. Plasma fact 18 in particular we had the vertical desktop support. So it was one of those features that was missing that needed to be re-implemented and we have a lot of those with well on. And this was one of the first. We had NVIDIA driver support implemented. So NVIDIA with their well on support chose a different path compared to all of those graphical GPU makers with their drivers. And so we need to have a particular implementation for this for the drivers. And then we at first the community want well the Queen developers didn't want to have something specific for NVIDIA. But in the end we pushed support for this driver as well because it's represented a good chunk of our users anyway. And so there was an important issue when resizing GTK 3 applications is well that got fixed then and a lot of small fixes. But I'm trying just to highlight the most visible and more important words to users. In fact that 19 we had we added the global menu that is really love to buy our users that want to have a similar workspace as OS 6 kind of workspace. Raman implementing the screen rotation. So we have good screen rotation. Working there was a fix with car runner previous to 5.19 would be hidden behind the taskbar. If the taskbar was on the high on top of the screen, it would be hidden behind and this got fixed the OSD OSD. So it's over the screen display got fixed in particular when plugging in and plugging your screens so that instead of being on the wrong screen or not in the corner of the screen. And the corner of the screen instead of the middle it would well at the right position and we got spectacular IDP support. IDP high DP support is really linked to well on because well on allows to have good high DP DPI support. And so we need to have a good support there and being able to do screenshots just so at least just so that you can make good bug reports was important. So so this gets implemented so that you can have your full resolution of the screen even though you are using a scale factor. In fact at 19 and in fact at 19 I want you to highlight this one is something that X couldn't allow us to implement is this feature here is the the here. It's the scroll speed. That's a kind of feature that X couldn't allow us to implement, but that well on allow us to add intermediate things and to to trick things that that was not possible. And it's thanks to this added power to the compositor that we can make such a thing. So this kind of feature couldn't be implemented and X, but we could and I expect more of those kind of features to appear over time. And in fact at 20 the upcoming release of plasma we will have in well on screencast better screencast support. I'm not to show what the end goal is to have OBS working, but I haven't tested it myself. But you could ask Alashif if I'm not to force coming on this subject. At least we have Windows thumbnails which are quite handy and will be working well. Another great feature by David Edmondson was the middle please pasting. So well that was my one personal feature that was missing for me to really be comfortable with well on. Although it has a small limitation in that it doesn't work with X well on X well on applications as of now. Great work by Vlad also is the subsurface clipping. So this is part of the well on protocols and it allows the better drawing of subsurface is well it's been complicated. But what you can gather from here it's an important step towards better drawing on the screen. And it's really important for some applications in particular for instance Firefox which on well on relies a lot on subsurface. And in fact at 20 we also improve stability and some other convenience thing we did for spectacle of the screenshot utility is you won't have to click on the screen to confirm when you take a screenshot. So that's one of the things that well on is kind of missing. We don't have a defined protocol for screenshotting. So we added our own protocol through Divas to all of this. So about upstream so we have been doing some work with upstream. With the well on community we are working towards proposing a way for instance to restart the well on compositor without losing the windows and keeping X windows also working so that to improve this well to be able to recover from a failing compositor for instance or for developers it would be really handy. And such we have been participating to the well on mailing list and we have been punctually talking with Qt well on developers to test their chains and iron out bugs. And well on is challenging well just to reiterate that the kind of thing that has been keeping us from moving faster is that well it's relatively complex but not complicated. It's just that also we have been working with a lot of Qt and Qt in some of our goals show in some part of its code show its age while KDE software has a lot of inheritance. And things that are hard also is working with upstream because then it adds a lot of well it's necessary work but it adds to mailing list a lot of discussions and so it just slows down the process when you're involved. So for instance so a lot of times we have been implementing protocols and then later we replace our own protocols with another we have an example with the layer shell protocols that have been evolving now to handle plasma surfaces and test bars so that it is not a specific KDE protocol anymore in the future. And community wise our current group hasn't expanded much and we are well and we are kind of working within our own group so it's a challenge for us to open our group better so that people can jump in and know better what we have been working on and how we can help them if they want to add their own efforts to the effort to the goal. So in the future well let's keep going let's keep it going we need to keep improving well on support throughout the stack towards expanding our user base and I recommend all of you to check it out sometimes after a plasma release for instance to try a plasma well on and find out if it meets your needs or report some new bugs. And we need to encourage contribution and in particular by keeping the community posted so I'll be working on the shortly on the Plasma 5.20 highlight of the new features we implemented for Wayland. And about contributing I'll let you tomorrow have a great presentation specifically about Queen and Wayland so don't miss this one if you want to get involved and thanks well should be it so I'm free for questions. Yeah we have a few questions the first question is are you forcing us to use Wayland or can we stick with X11 for the moment? No we are not forcing them users well from Wayland sessions are not as stable both of terms of stability and features so most users should probably stick with X. Wayland sessions are I would say subjectively currently at the end of an alpha phase so it's still missing a few features and still some instability that could pain some users. Still some users could find themselves better because there is a really well on effect of ICNDness that adds when it works. Okay the next question how concerned is current or future Wayland development with certain the next gaming applications and frameworks example this is wine proton native am I audible? Yeah I'm not a specialist on the question well here I know we are working because there are specific protocols in Wayland for instance to restrict the inputs so that an application can ask to get all the inputs except very rare ones like controller alt sub for instance and let the application take over the graphical so here I might need my queen fellow developers to help me respond further but I don't see a particular issue it's really a use case that we have in mind this part of the applications we want to get working on well. So the next question is how are you dealing with NVIDIA plus X Wayland support? I recall that getting NVIDIA to work with Wayland is different from getting it to work with X Wayland. Not sure well not a specialist on the question but X Wayland while we support NVIDIA on Wayland so I might not be good to answer on the qualified to answer this question it seems to me we should have support but I haven't tested that so I couldn't answer with confidence. Okay so we jump to the next question what do queen developers think about Wayland fragmentation and Wayland roots? Wayland fragmentation yeah well we have to recognize that Wayland is quite young still so there is still some and we have different communities interacting some of Wayland actors are more oriented towards embedded for instance or they want to have small screens and such so it's part of rooting out our solutions like X-Digital protocols are a better example where they are gradually expanding over consensus that has been building up over time so in fact well I know that we are working toward being more compatible at least with applications it's easy so I don't have much more to add on this subject. Okay the next question you talked about screencasting will Plasma have a built-in screencast recorder on Wayland or it will support existing screencasting apps? It will have existing screencast record application so what Alex worked on is to be able to advertise a pipe wire connection so that applications can pick up a stream video stream from the Wayland compositor and so a way to expose those streams to screencast and record applications that work on Wayland with pipe wires specifically.