 Hello everybody, I am Marco Martin and I've been a contributor of KDE since pretty much a decade. I've been almost always working mostly on Plasma, so that's exactly what I will talk about today. Nowadays I'm working for Blue Systems and I am still dedicating a lot of my time both free and work work on improving the Plasma experience. So this talk, even if it's about Plasma, will not really be that much about pretty pictures, but I'll go a bit more in-depth on the internals, how Plasma used to work, how Plasma works now, and how can we make it work in the future as we are starting to do some work and still get an idea for what we can and want to do for KDE F6 and Plasma 6. So Plasma began. Plasma began in the early days of KDE 3 to the KDE 4 transition in those very interesting times. So the first public release was with KDE 4.0. That's how it used to look. It changed a lot, luckily also, since then on the surface, but many of the internal concepts are still pretty similar and very valid today. So this first part would be kind of a repetition with the training by Caving on Friday, but we'll refresh it a bit and then go on what we can do for the future. So in the early KDE 4 times, Plasma was all built around a framework from Qt, which was called QGraphicsView. It was an early attempt of going over the limitations of the QWidget API. It wasn't completely successful because it was still very much software rendering based and QPainter based, but for sure it did teach many lessons. It's a way in Plasma 5, we ported it almost completely out of QGraphicsView. There are still some external applications that still do some use of it, like the Dolphin icon view. So how it used to work? There was a central class called the Corona that I guarantee back in those times Corona was a completely innocent name. Nowadays it probably really needs a new name for obvious reasons. The reason was with the Corona of the Sun, which is where Plasma lives. That was a subclass of a QGraphic scene. So the Corona was what contained every single graphical element that you seen in the Plasma desktop and Plasma panels. As the first level, this Corona contained objects called the containment that could have as many as we wanted. They could be desktop containment. So your desktop wallpaper with icons on desktop, widgets and whatnot. One for each screen and one for each activity. It also contained the several panels. All of them were containments. A containment was a subclass, and still is a subclass of applet, which at those time it was a subclass of QGraphics widgets. So applet was both the center of the logic of the plasmoid and of the graphical representation. A containment, as the name suggests, it could instantiate inside of it many, many applets. So it could contain the desktop could contain many widgets and the panel could contain many components as well. Your start menu, the task manager, decision try and whatnot. A plasmoid usually was a C++ plugin which extended subclasses either applet or containment. Later, we built several bindings of different languages. We had JavaScript that way before QML, but it was still not a thing. So it was JavaScript, but very imperative based and we had Python and Ruby. And just in the last years of KD4, we introduced the QML binding that later in Plasma 5 it grown up and it eaten up everything else because we were pretty fed up to be sincere with the QGraphics scene. So QML was also QGraphics scene based. In Qt4, in Qt5, it introduced its new rendering engine, the QML scene graph, and we wanted to go there also because with these completely software-based rendering, there were significant performance reasons, limitations like resizing a very big applet sometimes it went down to four or five frames per second which was really not acceptable. So we very enthusiastically jumped on the QML bandwagon. As a nice side effect, the triad of the main classes in Plasma became migrated from being also graphics objects to being pure key objects or purely logic without a particular representation attached, which is nice. As the downside, we lost pretty much all the bindings that were not QML, but we still had all the complete language binding infrastructure that we had even if it can have one and only one. And also those bindings were C++ plugins. So in Plasma 5, we have exactly one plugin for bindings that is the QML one, which is mandatory to use. So it doesn't really make much sense that it's a plugin. So this thing and this component is something that we probably can do without and we can simplify. So are we happy in Plasma framework as is now? We all know that it's way too big, it has way too many dependencies and it offers some functionalities that are still needed, some functionalities that are pretty okay, some functionality that are not really needed anymore, the kind of different paradigm that developed over time by development QML based UI made some of the framework redundant. So the part of layout loading with Corona Containment and Applet is fine. There are some important things to change there, but it's more or less good to go, I think. Well, the big thing is the containment, how it manages screen ownership, it does have problem with multi-screen, this will need a bit more thinking about. Some pieces can be, I think in KF6, they really should become their own framework. One example is all the SVG infrastructure. So to do basically exactly like we did back in the day with the K package, which was used to be a part of Plasma framework, SVG is based on top of Qt SVG, so it is still kind of limited to tiny SVG, but for what it has to do, it's fine. A library that loads basic shapes is something that it's always okay, but on top of Qt SVG, it adds pretty nice features. One of it is discussion, so by profiling things, we discovered that the biggest part of startup time while loading SVG is the actual instantiation and parsing of the SVG file, clearly. So it does on disk caching of the rendered big maps, which can improve startup time of almost an order of magnitude in the instantiation time of that particular thing. Also, another thing that is pretty nice in the Plasma SVG support is a basic style sheet support, so we can recolor some elements in the SVG according to the system colors. So it's very convenient. For instance, if you have a monochrome icon team, like most of the actions in the breeze icon team are, you can recolor them for a different color scheme without having to have a duplicate team just for different color schemes, at least one for light schemes and one for dark schemes. You can just recolor the same stuff. And also you can do pieces of the UI in SVG with those pieces that follow button colors and whatnot. We also have frame SVG, which is also pretty useful. It is the classical nine patches image used to do a style decorated render rectangles that you can scale without the corners being horribly deformed. On the QML bindings, it has also some basic support for hardware acceleration, so resizing them is very fast. But we still have a complete Q Painter API, so it could be well used both in Q Widgets based applications and QML applications. If at least if we get it on a low tier enough, the only concern for the tier is the use of KpxMapcache that rises a bit, but that shouldn't be bad. Another big part in Plasma Framework is data engines. Data engines is one of the things that were a really good idea at the time. They are a mechanism for having plugin-based logic based upon that extraction and right operation with a job API. They were thought mostly for the early imperative JavaScript bindings, so also to give those JavaScript bindings a kind of web-feeling-based API. At some point we also had support for remote data engines, so you could have a Plasma running on a machine fetching data from a different machine. It was a cool idea, but never really executed to the end. An idea that in my opinion in other places is still worth to explore, also with the help of KdConnect, I guess, but not with this API. Also that API was really subject of, made it too easy to do spaghetti code implementations, so most of the data engines implementation are really not pretty to look at, so it's something that we will probably retire. I already tried and did a standalone data engine library which could be used in Plasma 6 just as a working aid, could live in workspace with the name Plasma 5 support. Honor for a cumulplasmoid is much easier and much more elegant to instead binding ecu-object with properties, signals, slots and whatnot, just to pay attention of not doing big sync operations in the slots, as the data engines were very explicit of in them being very async, but in general, it did teach us many things, but we probably not need that anymore. Apart which is mostly okay until the step of the binding is the layout loading, so how does it work at the moment? The whole layout for the desktop is serialized in a configuration file, the appletsrc configuration file, the corona reads that and from the top config group called containment, it reads all the subgroups, each of the subgroups that is in the name of the structure of a number, so you had like containment like one, each group with this structure will represent a different containment, so corona will instantiate a containment instance for each one of them it doesn't matter if they are desktops or if they are panels, then each one of the containment restores its own config and then looks in its applets config group, so under it it will be an applets config group and then numbers again, so for each one of those subgroups it will instantiate a new applets which will have the containment as its parent in the key object sense and then the applets will restore its configuration and this is the part to slightly modify in my opinion, at this moment it loads the qml script engine plugin which then loads the qml and creates an object of a class called the applets interface which is a qquick item and is the parent of the actual representation that it's contained in the actual plus one qml, applets interface is pretty much a wrapper of most of the applets and containment api, so it's kind of redundant but is the thing that again gets registered as a context property as a context property in qml in the in the qml root context of that the template as that plasmoid object which you can see it used all over the place in most plasmoids implementations, you can access plasmoid dot form factor to see if you are in a panel or a desktop you can access plasmoid dot config to read or write the configuration and so on another part which i think it's pretty good and i will just improve on that is the concept of the shell packages those are also a collection of qml files distributed in a k package structure they are used to to customize a bit the behavior of the main windows so mostly the panel window the desktop window and the configuration dialogues and things like the widget explorer the activity switcher and whatnot they they were born in very late in the kd4 life cycle for plasmo active where we needed to have a plasma shell much more mobile optimized and the main desktop shell had a lot of qwidget based UI for those kind of things so we we added the possibility of of redefine all of that in qml and nowadays is used in the plasma desktop as its own plasma mobile as its own and also plasma big screen which both are based on a base package called plasmanano which it's more its biggest target is mostly just to be minimal i will later talk a bit about just a detail how i would make them slightly better then here those are the script engines the other part that i would like to eliminate so right now we have the applet script class in plasma in plasma framework that that then gets implemented by plugins and by c++ plugin in the only plugin that we have is the qml script engine that then implements its own almost complete applet api wrapper we should probably eliminate them even if i would like to eventually get back the Python the Python bindings but i don't think with this api it should probably just have the possibility of shipping python files in the packages i guess and then if found they execute it and the python file can do a qml register type for instance or whatever needs to be discussed i did a very small prototype for now but it's it's already pretty useful to to clear our ideas at the moment is the plasma framework fork which lives in my personal area on invent everything that does at the moment is is just loading a single view with a single containment with a single applet it in but it does have most of the required things in place just just just not all the polish all the things to be able to manage multi-screen and whatnot that will needed to be to be taught but with this with that prototype and with that refactor that i'm proposing uh should be possible also to to to lower lower the tier also of the the the framework significantly i still didn't fully get rid of kxml GUI use but i think that should also be possible then whether whether it's the result we live in in frameworks or in workspace it should be much more easy to maintain anyways so to recap uh we will have one one from from the the current code of plasma framework having one framework which is the svg stuff uh plasma framework will be gain will become basically uh corona uh containment the the all eternity and applet and not and not much more uh that's and the basic uh loading loading off of qml stuff also living there and and data engines uh data engines die all the script engine stuff die other things uh like the context the context menu plugins uh those can also probably live elsewhere just just in uh the final plasmasher implementation probably uh so the life cycle will would not change significantly um the part that corona uh parses applet rc and then creates the containment and then creates the applets and then containment create the applets from the config file that would not change uh the way on how containment are assigned to screens that needs a bit more discussion so i'm not sure yet um what what will change is that the view um when it uh it gets a containment uh it will ensure that the qml part of the containment is instantiated um and and then it will it will display it as the as the main thing of the view uh the containment uh will then instantiate the qml part of any applets uh not not directly not directly and not from the c++ part but from the qml part uh so only each applet pointer uh arriving even just created or or just created because it was it was uh uh restored for the configuration um it creates an instance of applet container which which points on applets and then applet container would create the qml part uh there will not be any more applet interface but we'll still have plasmoid in some form but uh should be better that plasmoid is just a pointer to applet directly um so on the on the applets side so on the plasmoid developer side uh the structure the same uh all the qml files in a k package i think that i would like is uh to force the root objects um of the qml scene to be a particular class like usually in quick quick controls in kirigami applications you have to have an application window and i would like to have uh to to have plasmoids need to be an instance of plasmoid representation which in my prototype at the moment is a q object uh that just provides two properties component representation of representation which are qqml components that gets created only on demand uh the plasmoid object that becomes the applets uh i would probably prefer it to be an attached property instead of a context property which are kind of evil this is a example code uh already kind of functional uh so you have as root applet representation and then uh you can specify a compact representation as it's today this compact and full representations they already they already exist and as is today compact representation 99.9 percent of the times you don't need that uh it will just be by default uh that icon that is defined in the shell package or you could set it explicitly as null null to say that you don't want it your uh your plasmoid it's always it's always um expanded like the taskbar that you don't want to uh to do that in a pop-up uh the full representation at the moment in plasma five is optional uh in plasma six would be um in plasma six would be mandatory as the root element is not a is not a is not an arbitrary item anymore and then from anywhere you could you could access plasmoid in this way plasmoid in any place of the qml code from any file that you call it it will always return the same applet pointer uh as i said i would like to have uh shell packages slightly more powerful i did not do experiments on that yet uh but uh at the moment the way they uh personalized like the panel window or the conversion dialogue or the desktop they define the root element of those windows what i would like to change is them to be able to define the window itself so um the shell package would contain a panel dot qml like now but instead of having an item as a root would have the panel view itself uh so on different on different shells you could have much more customized types of views that you may need in uh more embedded situations maybe maybe you want panels to not even be a view but but be in the same view of the desktop or stuff like that it has as a wild idea uh this kind of stuff so uh pluggable view types could also help if at some point we decide to integrate more with latte doc so latte doc is its own shell because it needs its own panel view with uh with very custom features so they could do that and we could even even load everything in the same plasmo process uh and having their own custom view uh just loaded as our panel but still is still still just a wild idea uh if anything of everything of that will be actually done uh for now are uh is just a very early prototype and also mostly my ramblings so um last the the the the paramount objective of course is to to have the least possible uh disruption and regressions for the user but we need to talk more about it and we will have a very long buff on wednesday on all things plasmon so if you would like to discuss but that uh just come there or find us in the usual channels and uh thank you very much i don't know if there is any time for questions or not but uh please do yeah change the model um there's two minutes left so maybe one okay by mate what do you envision for our long-term streaming story so he's eager about the spg-based streaming okay from our long-term team i do i do think uh the teams exactly as now uh need to be supported pretty much from the time for the time being uh because we have a lot of third-party teams from the store so that that should that should stay supported uh whether is the main thing probably in the early plasma six days it will be uh what's what i would ask santa about a teaming engine would be something a bit more probably a css based which can be used by plasma shell can be used by applications both q widgets and and qml applications maybe also still making use optional use of plasma svg svgs as one of the many of the many uh possibilities that that the css api would would give uh but but in the end some something something more unified even if in the end the user could still choose i want my panels to look completely different uh okay but yeah that would be a lot of work and and still needs to be well talked about okay i guess uh all other questions can be uh and talk about in the box okay thank you very much everyone yeah thanks michael thanks