 So in the next talk, Marco and Nicolo will present what Plasma 6 has in store for the future for us. Hello everybody, let's talk about Plasma 6. We'll get to the technical part of things with Marco. I don't know anything about that, but we'll talk about design and style first. So about that, the idea from the VDG that we had like some months ago was like to try to do some incremental style change. So without any big revolution in the design and the style. But whilst I was putting together the presentation, I realized that we did not do that and in fact we're still months away from the release and yet we have a lot of visual changes and redesigns and such. Not all of them have landed and are ready to be used in master but everything that I'm gonna talk about today should be in Plasma 6 if I'm not too lazy. So starting off with some stuff about Plasma itself, we've got a completely redesigned overview which yet again is currently not in master. It's in a branch, it's almost done. It looks completely different compared to what we have currently. It looks much more like to the GNOME overview with the Blur My Shell extension which I did use as a reference whilst implementing this. In here it's just the design that's different but it actually works completely different because it also now includes the grid view and the idea is that there are three states not like no overview at all and then normal overview and then the grid view and you should be able to switch from one to the next one or to the previous one instead of having two different effects it's just a single one that has both the grid view and the overview. Whilst doing that, the touch screen and touchpad animation gestures changed completely as well so now you can switch between the three states so as an example just by doing one swipe up with three fingers you're going to switch to the next state which is going to be the overview if you do it again then you're going to switch to the grid view and if you yet again do three fingers ups you're going to get back to normal and the opposite things happens if you go three fingers down as an example and the same applies to the touchpad so the gestures are consistent between the touch screen and the touchpad so it's a pretty big rework of how you interact like with your open applications and ideally this should make all the transitions a bit nicer and also if you're switching virtual desktop whilst in the overview that looks much nicer as well Next up we would like to have I'm sorry we do have already we have this already in master, it's ready the settings for the panels have been completely redesigned now they have these little drawings to show you what would happen if you click on each setting which I think are super nice looking and should be applied to everywhere in system settings and these however cannot be the last revision of the panel settings because we do have to change them again to change how we set the position of the panels and such because of some technical things that I think already happened but I completely lost track of them Next up we would like to have floating panels by default ideally it's a discussion that we're having but to do that they need to work a bit better so there is a merge request that has not landed yet which re-implements a lot of the features that floating panels have so now they do have a shadow they didn't previously and also whenever there's a window maximized they just defloat vertically without taking any more space as they used to do previously they had this big margin around them people didn't like those margins rightfully now they're just gone and it just floats towards the top or the bottom so that's nice and ideally who knows that might make the floating panels usable by default Next up, outlets are going to be redesigned too again this is very ongoing work so what we do have already are this couple of very pretty switches and the idea is that everything that gets applied immediately as soon as you click them is going to be a switch, not a checkbox and checkboxes are going to be used for things that you click and then you also have to click apply or it's some settings inside of an application but yeah, I do think that these switches within the outlets look very pretty We do also have a redesigned task switcher this comes from the Plasma Sprint just a couple of months ago and the idea is that we couldn't quite agree which one was the prettiest task switcher so we took a couple of them and just smashed them together so now we do have thumbnails for each application and we also have the icons on top of the thumbnail so that's going to make it much easier to switch to the right one So these are the things that are going to happen to the Plasma shell itself I hope that I'm not forgetting anything I probably am, but we'll also get more stuff when we get closer to the release date There's also some more stuff Ah yes, I almost forgot about this one, sorry So these are floating dialogues These are again not in master almost 3D and the only thing left is to decide how to expose them to the user and we also kind of have to decide if we want them at all If we do want them they're going to look kind of like this not by default but as an option either that can be toggled by the user or by the Plasma theme itself So you just put some margin in the SVG file as an example and then that's going to be applied around the dialogue so that it's floating This used together with the floating panel actually helps reduce the number of margin errors like some ugly stuff that happens when you open kickoff and it just like floats into nothing so it's a bit better looking with this option Again, might not be in Plasma 6, but who knows Next step is not Plasma shell itself stuff as an example, some things that are like stuff that can be reverted As an example, we do have a merge request going for a completely redesigned icons for places and dolphin stuff So this was started by Cameron Matt a couple, a year ago or something Luckily he wasn't able due to stuff to finish up the work but we now do have the draft and all the Python code that went with it and in fact it's a lot of Python code that completely automatizes the process of creating new MIME type icons and folder icons It's a super big thing that needs some Python developer help so if you know a bit of Python and want to contribute to KDE this could be a good starting point it's just some tooling that needs to be finished Next up we do have a redesigned mouse icon theme that if I recall correctly is currently in master I think it was done by Manuel again some thumbs up so I didn't look much of it it looks slightly different this might not be the final version but that's it So this is the final version that will for sure be in Plasma 6 and I think it's a bit darker and a bit prettier It's a bit incremental but it looks good We also have a redesigned if that's the word used for it sound theme which isn't on master yet but it is done It is a bit weird from a technological point of view how to deliver this one to the user because currently we do not have the concept of sound themes that you can just swap out we don't have a system settings page with a lot of sound themes that you can switch between So one idea would be just to replace all old oxygen sounds with these new ones It would be a bit weird but we can do that and there's a no from the audience so we are not going to do that Again, I'm kind of outdated on the latest info about these ones but you can check it out And finally there's also the idea of having some colorful window headers So the context about this this doesn't exist yet These pictures are edited and they're also misleading because you see a lot of different colors between windows That's not the idea The idea is that you have an accent color as always and that accent color is slightly applied to the window header that you're currently using It's going to be the same accent color for all the headers but only for the active window so that it's easier to actually distinguish what you're currently using from other windows Also, there's no MergeQuest order patch that currently implements this There are two different options One to actually paint the header bars but it uses a different color that's way stronger It's actually the same one as the accent color We don't want to go that route And the other one does tint the colors but it ints all of the colors of the window which is pretty cool but we didn't want to go that route by default So this is the idea You pick an accent color It's going to be slightly tinted It's probably not going to be as strong as I presented it right here This is just to see what's going on There is light to help you identify what is the currently active window From the design point of view I think that was everything If you have any questions, I guess that's at the end we're going to do And if I forgot anything again I'm really sorry but that's what I was able to come up with Okay, so now unfortunately the pretty pictures are over and there are boring technical details and code samples So bear with me, please Most of the rest of the talk will be about things inside the plasma shell itself and how plasmoid are written but it would be unjust to talk about plasma 6 without mentioning some important things that are coming in the other big, very big component of a plasma session which is queen Just three important things to mention in master already, queen it will support HDR So if you have the right hardware the right monitor if you run an application that natively supports HDR such as a particular game or a particular video it should work out of the box everything more colorful and beautiful Another big feature on Wayland which is very important for future parity with X11 is the restart support So until now on a Wayland session on any system, on any desktop if you had a crash on your compositor or if you just wanted to restart your compositor then you lose the whole of your session or all of your applications Now the applications will support the compositor going away at least a replication that supports the protocol and then the compositor starts and you should get all your applications running like nothing happened Another thing, not there yet but we are planning to support which could have quite some applications There is a new Wayland protocol floating around about workspaces that it's basically a virtual desktop protocol on steroids which will allow us to do things like different virtual desktop error activity or different virtual desktop error output which also ties on the further support of tiling that we will do in Quinn since apparently for tiling window manager users having different virtual desktop error screens it's quite of an important thing Now passing all the rest on what's happening in what is if you read the Plasma session so your panels, your widgets and what changes are in the Plasma library and how you are writing Plasmoids The rest of the talk will be about that because there are many third-party Plasmoids on the store whoever maintains that will have to do quite some work The good news is that almost everything that is around on-event everything on workspace and what not has already been ported but there are quite some important API changes So let's start with a thing we are getting rid of So data engines That was that concept that we had at the beginning of KD4 At the beginning we wanted to write Plasmoids in JavaScript that was before Qm 11 existed So we came up with a completely imperative API and the way to get data from your tasks like your notifications and what not from C++ source was we did that API It worked very well in an imperative work It doesn't really work We do have bindings from QML but doesn't really match well That job is done much better by QML extension So you write your Q object with properties and data models and what not and expose that to QML Now it's the way to do that So everything about that engines has been moved out of the Plasma It's seen in its own repo in workspace called Plasma 5 support So for the time being the existing data engines still work but we are planning to eventually get rid of all of that Second thing, SVGs We will still support SVG teams as they are You can think they are kind of getting along in the tooth That's correct And we eventually will have even some way to replace that We will not be for Plasma 6.0 It's something to think about in the future But in the meantime actually some things in all the SVG related libraries were quite useful For instance I heard many times that somebody wanted to have some simple SVG icons in its Android application but that wanted to color with a color theme and a cache on disk because loading SVGs on Android was not with Qt SVG was not really great In Plasma there were classes to do exactly that Couldn't use them because all of the dependency of the Plasma that depended from everything Now all of that has been moved to a different framework called KSVG Basically recycling the name of an old dead one but that's fine So it's Plasma SVG, Plasma Frame SVG So still supporting the nine patches thing Everything about Qt SVG is not exposed in the public API So in the future we could even in a compatible way switch the backend if need arises For now if you were using it porting it, it's very simple It's just pretty much just the changing the import changing the namespace and it's okay All the old API still works for simple SVG items You are now just recommended to use this more compact form but the old form still worked A nice addition is that this framework has compared to the Plasma version if you had SVGs that support all the stylesheet stuff to have like a rectangle with the same color of the system color background Now this works with normal system colors It integrates with Kirigami and the Kirigami team class So even if you by hand replace a color then in your SVG that depends with the new color as well which is nice On the C++ side there is this image set class where you define where your SVGs are so you don't have to use a Plasma team In your application you can have any set of elements and files you want and you can ship it, for instance, in the data application of your application or together with all the QML files or whatever you want, you control it with this class Yeah, that's basically it The biggest headache if someone wrote a Plasma another party Plasma on the store the biggest headache is a big change in the Plasma API Also the Plasma API still had many components from the old imperative JavaScript API and we wanted to get rid of all of them So you had still this magical context property which is not a good thing to have in QML called Plasmoid which was a QQQ item that wrapped most, not all, kind of similar but not exactly the same API of the central class of Plasma as Plasma applet Now you only have the uppercase Plasma so an attached property version which is directly the Plasma applet instance so you can use basically 100% of the API or everything that is exposed in the API as properties, invocable signals and whatnot What was that QQQ item? It became a graphical element called Plasma with the item that now must be the root element of your Plasma So comparing these we used to have any random item as the root item and then put the test properties for full representation So basically this full representation will always be basically your item So in most of the Plasma this actual graphical item was not shown anywhere in the scene which was kind of weird Now you declare it like that and this will be the actual root object in the scene of your Plasma The more semantic properties like title, like the status if it's expanded or not are still of Plasma which is now the applet and the purely graphical ones like the actual representation or compact representation are direct properties of that Plasma item but the main thing that changes Another thing that was completely taken from the JavaScript API was the Actions API Basically a Plasma can just add an arbitrary number of context menu action if you right click on its icon on the panel or whatnot It used to have this API that is very imperative So in uncompleted then a bunch of JavaScript which created internally this call created internally a QAction and then if you wanted to bind something you even had to use an imperative API for property bindings and then to react when the user clicked that you had to declare a function with a kind of magical name so if this was previous it was actually previous Now on the attached Plasma object contextual action is a list property so you just declare a list of everything you need and then the action you just you just put it declaratively with all the bindings and whatnot This action type is actually an actual QAction because there are things that still go from KML to C++ back and forth so they are not KML actions It's something that I would really like that was supported in QML the fact that the QML actions are not real actions it's still something I'm not completely happy so hopefully in the future something better we will have Another thing that changes in how things are done So in Kirigami when we first designed it we had lifted pretty much one to one some concept that we were using and like in Plasma that we could not use there again because of dependencies that brought out quite some code application basically two big classes Plasma Team and Plasma Units So Plasma Team for all the colors so I want a background color I want a text color whatnot that comes magically from the proper color team but over the years the Kirigami version got much more advanced than the Plasma version like this inheritance so I can say the Kirigami team of this item is a header so if a header has different colors everything in that item also the sub-items will have colors from the header which is possible because it's an attached property that inherits in the whole tree of the scene while the Plasma version was a singleton so it was the same for the whole application it didn't really work also in Kirigami for some reason the application wants that in that particular part in all its children the background color is not normal but it's a particular shade of purple for reasons it works So in Plasma 6 that team will go away just use the Kirigami version units that it's for animation and duration layout spacing and whatnot also that use the Kirigami version another class that was in Plasma was ColorScope that was implementing that color inheritance that I talked before also that goes away from Plasma 6 so just use the Kirigami version a blocker that we couldn't do that in Plasma 5 was that we may have to need two different teams so like Plasmoids need colors that come from the Plasma team configuration dialogs needs colors that come from the system team by default those two are the same thing but some Plasma teams have their own color sets so we have to base where we are we have to return the proper colors now this works so that's fine so also units I use the Kirigami version icons we had a particular widget for displaying icons in Plasma that was also duplicated in Kirigami didn't make any sense so use only the Kirigami version it's kind of unfortunate that one to display icons that properly works is not really in QML base but at least we have only one implementation instead of two so most of the work in Plasma 6 was actually to make it way smaller with much less color to maintain so hopefully let's bug the so any question both of my part and Nicolo part Noa so regarding the floating dialogs are you gonna like have a way to have a little arrow that points to the part to the little applet that's been requested actually implementing that would be quite painful to say the least so I would be inclined to say currently no, ideally I would like to have that understandable it's possible it's painful it's not technically impossible all the dialog also one thing that I forgot to mention all the implementation of those pop-ups the CD dialog class was quite of a mess internally as being rewritten so that may make it a bit easier to do in the future so I must say I'm sick and tired of oxygen sound so I'm glad that there's finally something new coming up I'm also happy that you look into the XG sound scheme spec which is something I've wanted to implement for the longest time so we should have a chat about all of that if there's anything else you need that might be still floating around on my computer that you could find useful so very nice work on the whole sound stuff let's bring back the broken glass sound so now that we have the ability to use kirigami themes theme stuff can you touch a little bit on the blockers to unifying the actual component sets themselves such that we could also get rid of the duplication between the kirigami and plasma versions of things like placeholder message label things like that right so there is still one problem to just use every single kirigami components in plasmoid still for the same problem of having to support two themes in the same process so for everything that is just colors like just label headers and things like that we now can use it without problems everything that uses Qt quit controls so like if a controller has inside a button then that becomes a problem because simply the import Qt quit controls do gives you only possible theme per process because it's how the button type is registered so we cannot have two and that is still an unsolved problem in Qt 6 unfortunately no more questions then thank you Marco