 Hello everybody and welcome to yet another amazing talk at this year's Academy. The next talk will be about KDE Frameworks 6 or the next KDE Frameworks and it will be given by Dr. Kevin Ottens, the guy who is main in code reviews and very, very nice in person. Hello Kevin. Thank you even. All right, so let's get started with this. Welcome everyone to this talk. So the goal here is to give a rough overview about how KDE Frameworks is structured and I will cover in particular at the end an idea which has been discussed during the last KDE Frameworks print and admittedly that part is more or less food for thought for the upcoming KDE Frameworks 6 both. First for those who don't know me, so I started to use KDE as a teenager basically, so way back in the time. I didn't start contributing right away and waited a few years before doing this and when I did that, that was love at first sight. I love the community back then. I still love it nowadays and so I've been doing things here and there. In particular I've been stuck quite a bit in KDE Libs and I participated in the setup of the KDE Frameworks architecture. I also do some community stuff, so I helped with facilitating the creation of the KDE manifesto and nowadays you might have seen some of my blog posts where I'm using in community data analytics to see how communities are doing and of course in particular KDE or subparts of KDE. Shameless plug, I will have another talk about this with a colleague of mine next Friday and so nowadays I'm working at a new cloud culture where we are doing services around development and mostly tech leaders of service type jobs, architectural jobs and so on. And I'm living in Toulouse, so in the southwest of France. Alright, those who know me, those who attended the training yesterday, they know that I generally start with some historic bits, so that's what we are going to do now and go back. Alright, apparently it's too loud. I can probably do this, yes. So way back in the time, not right at the beginning but somewhere in between, we had something that we called the KDE platform which was basically KDE Lebes and something named KDE base runtime. The thing at the time was that we had a rather monolithic development model and because of that it was not that easy to actually know the dependencies where they went, that was a bit ad hoc. So if you took something like Plasma desktop and looked at the dependencies, it might not be reliable for everyone, I think I can actually zoom in, yes. So you get to see that the Plasma desktop for instance would direct, almost directly link to libk text editor, which would then pull in libk parts straight from Plasma desktop or that you would have WebKit LinkedIn, so lots of weird dependencies you wouldn't expect. Even things like KDE in it, you would have links to kpart and to kio, so that would bring quite a lot just for something rather small as a service. So with Plasma, you would see kio being linked directly, libk file being linked directly. So that's kind of what you get as, I was about to say weird, but that's more surprising dependencies when you have more of a monolithic model. You get dependencies, which makes sense, and then you get some others which are more opportunistic. Well, it's just there in the same repository and we release at the same time, so that's probably fine, right, if I just link to that. That's how you might end up with a big ball of mud at some point. So back in 2010, there's been one of the Plasma meetings, which were called Tokamaks. So during the Tokamak 4, in the snow, there's been discussions around that, right, and where someone basically took an axe and decided to do something about the world problem. That led to that presentation, which was, so that screenshot of the first slide named kd platform profiles, low-fat kd platform for your pleasure. And between the parentheses, if you look, there's the kd53, right, no added sugar. So that was even before we considered, you know, going to, really going to put five and coming up with kd frameworks and already back then there were discussions about how can we do better regarding the dependencies. And the idea of the platform profiles was to say you could have the desktop profile with everything and all the dependencies, right, and then you could have, if I remember correctly, that was something like a tablet profile. So you would, we would cut at compile time for that form factor, some of the dependencies, and then you would lose features. And then for the mobile, we would cut some more dependencies and then you would lose features, right? So that was kind of a stop gap measure to try to bring less dependencies because you're going to smaller and smaller devices. Obviously, that was kind of influenced by the presence of a famous bootmaker around the community at the time. That never was really satisfactory, right, the world. We do it at compile time. So that means it's actually harder to test and validate in QA. And because then your test matrix is just bigger, right, you have to compile with all the different type of flags. And the fact that you would lose features, right, and one of the things is that we want all of our libraries to work well together and provide a very integrated experience when you get them. And there was no way to reclaim that experience, right, if some stuff was installed. So fast tracking, more than a year, that's where we had the platform 11 meeting, which means that was 10 years ago now, right, that was in June 2011 back then. And so we've been looking at more of those graphs. And so for instance, the Acquanity console dependencies, which was a good one because it tended for various reasons to link to everything. So I looked quite a bit to that one, because we could see plenty of the different pathways in your dependencies. That was something we did in a cabin in the Swiss Alps, basically. So when you go there, a bunch of kids in a cabin, what could possibly go wrong, right? More precisely, right, you get a bunch of geeks in the middle of nowhere. So they just spend their time with codes and graphs and looking at stuff, right? So that was actually a very, very productive meeting. We ended up lining up quite a lot of tasks. That picture was taken in that particular cabin at the beginning of the meeting. So you could see that all the tasks, most of all the tasks are on the left hand side. And I don't remember the number that was really huge. And that's pretty much how it looked at the night of the last day, right? So everything is on the right. So a lot of stuff was done there. Most of those tasks were about looking at each libraries and each problematic dependencies we identified in those libraries. So it was a lot of work from quite a few individuals during that meeting. And that's how we came up with the KD Frameworks 5 dependency plan. So there are several things to notice in there. So I know that Volcker regret the color palette, which is used there, but that's your fault. So you have to leave with it now. But one thing you can notice is that we already see, you know, those rows, those columns, right, which says, well, the tiers, right, the idea of the tiers already, right? And we get the columns for the different type of frameworks, which is something we still roll with nowadays. There are a few things which are a bit forgotten. So for instance, if you look at kparts, right, kparts was meant to be in that particular box, which we call look and feel and consistency. It's not at all how it ended up, right? It has a very different structure. kparts is in tier three. One thing you might notice, which I think got a bit lost in time, is that we had different shapes for them, right? Because we were looking at that core, that grid, that widgets, right, or some stuff which is mixed, right? And we would try to actually separate between the widget stuff and the grid stuff and the core stuff in different frameworks. We kind of relaxed that when we re-arrived at the latest model. And so that's the organizational matrix, which is still valid today. So it should look familiar, I think to almost everyone who's been looking at the documentation of KD frameworks, because if you look at the API documentation, they are actually sorted, right? You have several tables, one per tier. So you get the tier one, tier two, tier three. And so at least those should look familiar, right? But then we have the types, right? And so we have that solution type and we have the integration Qt add-ons and then we have functional Qt add-ons. And if you look, they have dependency rules as well, right? Because we always talk about where something which is in tier three can depend on something which is in tier three, right? Or on something which is in tier two. Something in tier two can depend on tier one and something in tier one can depend on nothing else than Qt and system like this. That's basically what we have at the bottom. But then that was actually a bit more complex than that, because if you add a solution in tier two, because it's tier two, it can depend only on tier one stuff, right? But then it could depend only on solution tier one or on functional add-on tier one or integration add-on tier one. Now, if I have an integration add-on tier two, it's supposed to depend only on integration tier one or functional tier one, right? And we kind of lost that in the conversations, right? So I think that's the reason why we kind of lost this and I'm going to eat in a minute. The reason why it's a bit unfortunate that it got lost, is that in a way, when we had discussions back then, we were thinking that moving a framework in that matrix wasn't only about moving it down, which is then kind of what we've been spending quite some time doing, right? Which is cutting the dependencies at built time and then moving it down in the tiers. But that was also about moving it toward the right, if that makes sense for the particular framework, to move it toward the right, because those are more about the runtime dependencies. So we wanted to get that streamlined as well. So here is my take on why we kind of lost the types along the way, is that if you look at the policies that we have around frameworks, that's the description of the type, which I took the extract there. But the constraints from types are the following. Functional Qt add-ons cannot have runtime dependencies, easy peasy, right? Integration Qt add-ons can have an optional runtime dependency and aim at integrating with the underlying operating system slash platform. It's becoming a bit odd, right? Because it can have a runtime dependency or not, right? But then there's an intent. And then you have solutions which have mandatory runtime dependencies because that's part of their design and where their id values come from. Scalability, resource sharing, resilience and so on. That sounds complicated, right? I mean, it's complicated because in particular you have one where it's a bit mixed up between the presence of runtime dependencies or not, right? Depending on the platform and then there it's mixed between this and the intent, right? It might not have any runtime dependency, but if the intent is integrating in an operating system, then it ends up there. So it's kind of, it feels messy and for solutions, it's even worse, right? In a way. And so because of that complexity, I think that's why it never quite picked up in conversations. And somehow it was a bit clumsy attempt, right? I'm trying to draw the line between this about a portable API which abstracts from platform facility or it's an API which is more of a building block to make platforms, right? Because we're in that situation where we are both making a platform and we are making applications, right? That's kind of what we do. We try to do both over time. And so we're trying to draw that line somehow, right? And we can never quite manage to do this. So now we kind of catch up with today, right? The model which is in place with framework, so we see that we have that two by two, three by three matrix. And unfortunately we use that more like as a single vector and we kind of lost the rest. In the metainfo.yaml, though, both information appear. So we can do stuff with that. So I went back to some of the old scripts we used to plot the dependencies and I started to do it again with the AT frameworks we have today. So what we have there is that each blue dot is actually one of the AT frameworks. And then we have an arrow between two of them if one depends on the other. Or the layout I forced it so that each layer maps to a tier, okay? So we have tier one at the bottom and we can see that there are plenty of them where no other frameworks actually depend on them. And then we go one developed tier two and then one developed tier three. Which explains why you see some of the horizontal dependencies, right? Because tier three can depend between each other. Now let's try to make this a bit more visual. So red we got the functional framework there, green that the integration, and then blue that the solution frameworks, okay? So all RGB. And so we start to actually see them, right? Then the obvious question is, because we lost the types in the conversations, is are we actually respecting the rules we gave to ourselves? Which is that I cannot have, for instance, an integration framework which would depend on a solution framework, right? Or a functional one which depends on a solution one. Which means you need to start coloring the rows as well, right? So you color them by the type of the framework having the dependency, right? And not the dependency itself. So that would be important in a minute. Because now if we zoom in, we start to see stuff like this, right? So my green dot there, so that's a zoom from the previous one we had, it's fine, right? We got two solution frameworks which are depending on an integration framework. Because remember blue that the solutions, so we see two blue rows coming. So they're coming from two solutions toward an integration framework. So for three by three metrics, that's fine, right? Then the red dot is okay as well, right? We got one solution and one integration framework depending on a functional framework. We're still fine. And then we got that blue dot. We got so one solution framework depending on the solution framework, right? A blue arrow which arrives on a blue dot, so we're fine. And then we got one functional framework depending on the solution framework. And there are the rules we gave to ourselves. That's supposed to be forbidden, right? So that's a rule here, right? Is actually a problem, right? We actually violated one of the rules we gave ourselves for KG frameworks five. All right, so definitely something is issue with the types, right? They are to understand they didn't quite play their role in the maturity system we envisioned, right? Because we never quite pushed frameworks toward the right in that matrix which I was showing earlier. It's one extra dimension so that makes more things for people to think about and that's why they kind of focus on the tiers because they were easier to understand. And as we see, there are clearly a few mistakes in the metadata, right? That we have due to the above, right? So let's ask the question, can we do better than this? So I think the problem we have here is that it's conflating two things, right? It's conflating system abstraction and implementation in our frameworks right now. So if we go back to the original intent of the types, that was to avoid conflating those two in the frameworks, basically. So we provide platform abstraction for portable apps and so in that way KG frameworks is an extended cute. But we also make building blocks for our platform, right? So Plasma on top of X11 Wayland, on top of some POSIX system, right? That's pretty much what we do and we do both and there's a tension between those two. And that tension is not quite resolved and both are inside the KDE frameworks product, right? And that's kind of unfortunate. So the idea which was a bit discussed at the last KDE frameworks was to maybe say have a different product, right? And to start saying, well maybe some of that stuff shouldn't be in a way shouldn't be in KDE frameworks, right? That's kind of a different conversation but at least shouldn't be labeled as KDE frameworks, right? Because the expectation for people that KDE frameworks, that's APIs you can use as an extended cute. And for some of them, it's not quite true, right? If you take K-Wallet, it's not quite true. You're actually linking to a particular implementation of a password store, right? And so there was this idea of saying, well maybe there's some stuff which should be labeled as the Plasma API, right? Because that's the building blocks for all workspace for all full operating system if you wish, which we call Plasma, right? And so I went with looking at the frameworks and saying, okay, which ones are actually in that situation, right? So Baloo is kind of K activities as well because K activities have no equivalent on other platforms, right? So it's platform specific due to this. K Global Accel as well, K Notify Config, K Runner, obviously, K Wallet as I mentioned Plasma framework very probably, right? And Purpose. So the idea behind Purpose is actually something which could be portable, right? But what we expose is one particular implementation for us. It's not abstracting you for actions which would work on Android, for instance. And of course there are more of those libraries which are actually released with Plasma itself, right? But that's out of scope for what I'm looking at right now, right? I'm really focusing on KD frameworks. So should applications use those APIs? Yeah, sure, why not, right? But they have to know that when they do this, they have a reduced portability, right? And so that if they want to do things well, they need to have ifdesfs. This is Plasma specific as soon as you touch one of those. And so that's similar to using Windows or macOS APIs directly, right? They just happen to be APIs made with Qt, but they are still non-portable APIs. So let's go back to our coloring dots, right? With that in mind now. So let's say that instead of having the functional and integration and solutions, I have only two colors, okay? And so I will have the ones which are not part of the Plasma API as I defined it on the previous slide, and the ones which are part of the Plasma API, okay? So the red ones are part of the Plasma API. You will notice that none of them are actually tier one, right? Which is somewhat unsurprising because that's for platform where we use our frameworks, so yeah, that kind of makes sense. And so in that set of what would be forbidden, what would be forbidden is a non-Plasma API, so something in gray depending on the Plasma API frameworks or something in red, okay? So we have our time to spot that still and changing the layout actually makes that a bit better. So you might see that there's something fishy going on in that particular area, but there are still too many edges, right? So if we filter out the allowed edges and keep only the wrong one, right? We can see that there's something fishy here, something fishy there, right? And that layout is still not so let's remove completely the ones which have no dependencies left, right? And that gives us the offenders, right? So at that point, we know we're offending. And so there's not many left in there, so it's time to name them. So we have our shortlist of offenders that way, okay? We know that KIO is depending on K-Wallet, so that's a valuation of something non-part of Plasma API which depends on it. And then we got XMM-Qui and K-Declarative depending on K-Global-XL. Now we need to go one level deeper to actually know what inside of those frameworks does those dependencies. And what we find out is that inside of KIO that's just K-Password server depending on K-Wallet. And for K-Declarative and K-XMM-Qui, it's really they are depending on the library of K-Global-XL and that's mainly because why they have GUI to deal with shortcuts, right? In the future, what can we do? Well, we have very good news from that exploration idea that not too many dependencies to fix. So that's very good news, right? There's basically only three right now which are which would be out loud if we would go for a Plasma API approach. And we still want to have something final trained. So that's why I used FD Sector for that because now we want to get very precise and use a scalper to cut whatever needs to be cut. So for KIO, K-Wallet, this dependency, that's basically K-Password server, as I said, which uses just stuff to check a wallet, right? Open it and then check if a key exists or not, right? That's basically the gist of it. My easy solution, right? We are talking about QtKeychain to eventually moving inside K-D frameworks. QtKeychain is a platform abstraction, right? So it can talk to K-Wallet, it can talk to you, to the key ring on Mac, and the equivalent on Windows, right? So just port K-Password server to QtKeychain, so that one is easy. For K-Global access, so there's a few more which are used, right? So we see that the default shortcut and the shortcut by keys and getting the shortcut for an action and to know if a global shortcut is available, right? All of that is used. We also get things about the shortcut info, right? And the dependencies, so where it gets interesting though is looking at where the dependencies come from, right? So they come from key sequence widget, action collection, shortcut edit widget, shortcut editor, shortcut editor item, and KXM and GUI factory. Use cases when you start sorting them by looking at the code in those and how they use the dependencies listed just before is basically setting, getting the color shortcuts, checking conflicts, ending the shortcut settings, and reacting to a global shortcut which changes. We have potential solutions for that. So it's already inside of KXM and GUI, the work is already done to if death all of that, right? It already has an have global access if death. This is a good starting point, okay? Now the downside to that is that we would have to decide at compact time. So I think what it misses is a strategy similar to what we have for K-Message Dialogue and France, right? Which is to have some sort of facade to abstract away the uses and then to have framework integration, right? So that would be our plug-in interface, and then framework integration could deliver the plug-in like it does already for a few classes inside of frameworks. And so this way we would have cut the dependency, right? We're still having all the features if both frameworks are installed plus the framework integration. So in that case, that becomes a deployment question, which is where we want to be at. Okay, declarative to our K-Global Accel that mainly comes from similar things inside of K-Quick controls private plugins. And same thing, it's because it has something which is called a key sequence item, and inside there there's a key sequence helper. The only use case there is checking for conflict with global shortcuts, right? That code is pretty much duplicated from XML GUI by the way. Good news, it's relatively self-contained though. Potential solution for that one. It's a very simple thing, maybe just have a D-Bus code for that one. It's just about checking conflict, right? So just question and answer. D-Bus could do the job in that case. That seems to be a common use case though. So if we go for that solution instead of the facade in declarative, we should probably remove the facade. We should probably remove the particular check from the facade on the XML GUI site. All right, right now. So obviously, I mean, if there's agreement on that, then tasks should be added in the KG Framework 6 workboard. And that would be like one task pair unwanted dependency to solve. I didn't go around doing this because as I said, that's kind of food for thought for the upcoming both. So we need to settle on the solutions we want to pick for each of the cases first. And then we just have to implement the task. Again, the good news is that there are not many of them, right? And so then what? Profit, right? Well, not quite. Because what I cover there, that's basically just the technical bits. The real challenge is that they're after that, in fact. Because then that means that we solved, as I said with your scale purchase, a few of those, right? But then what happens about that big drift that I'm drawing between frameworks and Plasma API? That's the open question. Do we move the Plasma API frameworks out of KG Frameworks? And that would have community and release management implications, right? Where do they go? Should they be in a separate product released at the same time than KG Frameworks? My personal opinion that they should probably be within Plasma, because there's value to release them in sync with Plasma releases. I mean, there's a reason, for instance, why we've seen the KYLM server bits move out of frameworks to go in Plasma. It's just a lot of headaches when you have stuff which is released at different times where you have only one, you already have one primary consumer of them or implementer of them. Obviously, that means that the Plasma team would have to commit to some ABI or ABI guarantees, similar to the KD Frameworks one, for those parts of Plasma, right? For the Plasma API framework. And of course, that's also as marketing implications, right? Because I'm not quite sure how we would communicate about this more widely. And obviously, we don't want to come out with the same message if it's on the KD Frameworks Recycle or if it's on the Plasma Recycle or something else, right? All right, that's everything I had in store for tonight. We still have a few minutes, but not many. If you have any questions, I will try to answer. So the first question is from David E. of anything relevant both. That should be on Monday morning. On Monday morning, okay. I hope he's satisfied by the answer. I think that's 9 UTC. Then he's not satisfied by the answer. So I just wanted to applaud the great work and obviously the great talk. All of the questions that popped up during the talk were answered by the following slides. So I kind of deleted them all because they were already answered. Perfect transitions then. Yeah, exactly. So this was, I guess, the most professional talk that we had so far. No questions because you answered them all. Just to say off. Okay. And it seems that nothing else is happening. So thank you again. And everybody give a warm applause to Kevin in the chat. Thank you. See you in 9 days. See you around.