Nicolas 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 BlurMyShell extension, which I did use as a reference whilst implementing this.
In here it's just a design that's different, but it actually works completely different because
it also now includes the GridView and the idea is that there are three states,
no overview at all, and then normal overview, and then the GridView,
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 GridView 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 gonna switch to the next state, which is gonna be the overview, if you
do it again then you're going to switch to the GridView, and if you yet again do three finger
ups you're gonna get back to normal, and the opposite things happen 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 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, oh no 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, again not landed yet, which reimplements 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, 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,
the applets 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 applets 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 on 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 gonna make it
much easier to switch to the right one. So these are the things that are gonna 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, then they're gonna 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 gonna 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 up is not plasmashell itself stuff, as an example
some things that are like stuff that can be reverted. As an example we do have a merge request
ongoing for a completely redesigned icons for places and you know dolphin stuff, so this was
started by Kenver and Matt a couple, a year ago or something, and 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 manual,
again some thumbs up, so I didn't look much at 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 plasma6
and I think it's like 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're not gonna 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 merge request or 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 so we don't want to go
that route. And the other one does tint the colors but it tints 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. Just something very slight to help you
identify what is the currently active window. And 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 gonna 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 plasmoids 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 KWin. Just three important things to mention. In master already
KWin 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 every application that supports
the protocol and then the compositor restarts 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 more 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 KWin since apparently for
tiling window manager users having different virtual desktop screen it's quite of an important
thing. Now passing on all the rest on what's happening in what is purely the Plasma session
so your panels your widgets and what changes are in the Plasma library and in 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 whatnot has already
been ported but there are quite some important API changes so let's start with a thing we are
getting rid of. Data engines that was that concept that we had at the beginning of KDE4.
At the beginning we wanted to write plasmoids in javascript that was before QML again existed so
we came up with a completely imperative API and the way to get data from your tasks like your
notifications and whatnot from C++ source was we did that API. It worked very well in a
imperative work it doesn't really work and we do have bindings from QML but doesn't really
much well that job is done much better by QML extensions so you have you write your
your QObject with properties and data models and whatnot and expose that to QML. Now it's the way
to do that so everything about data engines has been moved out of libplasma 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
long in the tooth that's correct and we eventually will have even some way to replace that
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
that but that wanted to color with 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 dependencies 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 in the
future we could even in a compatible way switch the back end 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
that this framework has compared to the plasma version if you had SVGs that support all the
stylesheet stuff to to have like a rectangle with the with the same color of the system color
background now this 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 will be paints 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 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 plasmoid third-party
plasmoid on the store the biggest headache is a big change in the plasmoid api also the the
plasmoid api still had many components from the old imperative javascript api and we wanted to get
rid of all of them so you had this still this magical context property which is not a good
thing to have in qml called plasmoid which was a qquik item that wrapped most not all kind of
similar but not exactly the same api of the central class of plasma is plasma applet
now you only have the uppercase plasmoid 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 has properties invocable signals and whatnot what was that qquik item it became
graphical element called plasmoid item that now must be the root element of your plasmoid so
comparing these we used to have any random item as the root item and then put the attached properties
for like full representation so basically this full representation will always be basically your
item so this in most of the plasmos these these actual graphical item was not shown anywhere
in the in the scene which was kind of weird now you would declare it like that and and this
will be the actual root object in the scene of your plasmoid the more semantic properties like
title like the status if it's expanded or not are still of plasmoid which is not the applet
and the purely graphical ones like the actual representation or compact representation for
representation are direct properties of that plasma item that 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 like on
its icon on the panel or whatnot it used to have this api that it's very imperative so in uncompleted
then a bunch of javascript which created internally this is called created internally a qaction and
then if you wanted to bind something you even had to use an imperative api for for property bindings
and then to react when when the user clicked that you had to declare a function with a kind
of magical name so if this was previous it was action previous and then you have your code
now on the attached plasmoid object contextual action is a list property so you just declare a
list of everything you need and then and then the action you just you just put it declaratively
with all the bindings and whatnot this action type is actually a natural qaction because are
things that still go from qml to c++ back and forth so they are not qml 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
another thing that 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 that we could not use there again because of dependencies that brought out quite some code
duplication basically to 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 come magically from the proper
color team but over over over the the years the the kirigami version got much more advanced
than the plasma version like this inheritance so i can say the kirigami theme of this item is
an header so if 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 that's
narrates in the whole tree of of the scene while the plasma version was a singleton so this was
the same for the whole application 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 six a team
will go away just use the kirigami version units that it's for for duration animation and duration
layout spacing and whatnot also that use the kirigami version another class that was in plasma
was color scope that was implementing that in color inheritance that i talked before also that
goes away from plasma 6 so so yeah just just use the kirigami version a blocker that we couldn't
do that in in 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 dialogues needs colors that come from the system
team by default those two are the same thing but some plasma teams have their own core set so we
have to base where we are we have to return the proper colors now this works in plasma 6 so so
that's fine so also yeah 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 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 yeah most of most of the work in plasma 6 was actually to make it way smaller with much
less code to maintain so hopefully less bug so any question both of my part and nicolo part
so regarding the floating dialogues 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 like ideally i
would like to have that but understandable it's it's possible it's it's yeah it's painful it's
not technically impossible all the dialogue also one thing that i forgot to mention all the
implementation of those pop-ups the edi 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 log 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 or if there's
something that might be still floating around on my computer that you could find useful but yeah so
very nice work on the whole sound stuff and 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 say 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 teams in the same process
so for everything that is just colors like just label headers and and things like that we now can
use it without problems everything that uses Qt Quick controls so like if a controller is inside
a button then that becomes a problem because simply the import import Qt Quick controls
gives you only possible team 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 and thank you Marco and Nuclo
you