 All right, hello again. I'm saying again because we've been here before, not here, here, but at Academy. First time being in 2021, where I talked about what's cooking for KDE Framework Six, where it's sort of elaborated and presented on various ideas and goals we had in mind for Framework Six. At the same Academy, Kevin Ottens was presenting KF Six, the architecture overview, where he had a sort of more architectural approach and description in mind. And then in the next year, I was at Qt DevCon, which is a developer conference more focused on Qt, where I also talked about our way to Qt Six and a bit about KF Six. And then of course, there was Academy again. So first of all, last year, Volker talked about the plans and progress in a short talk about where we were back then. And then Alex and I had a longer talk about some more in-depth topics and how to port your apps to make use of KF Six. And then later that year, I gave a keynote at QtCon Brazil and where I also talked about our journey to Qt Six and beyond. So you're starting to see a pattern every year at Academy, there's one more person on stage, but you can be assured next year there won't be four people on stage because this is going to be the last Academy we're gonna talk about, KF Six, hopefully. So how did it all start? The first time we started talking about KF Six was also at Academy four years ago, which is a long time by now, in Milan. Qt Six wasn't out back then, but it was on the horizon, so it was ample time to start thinking about that. And that's what we did in a both session. And a couple of weeks later, some of us met in Berlin for an in-person sprint back then when people still did in-person sprint. And talked about it and we discussed ideas. We set out design goals. We came up with a huge work bot and fabricator that at some point had close to 500 tasks on it. And we of course started working towards that. And then two years later in 2021, we did another sprint this time online for reasons, which was used to sort of refine the work or discuss some of the items that need discussion and just generally make progress. And at some point we also started having regular online meetings where we once a week or once every two weeks got together for an hour and discussed various topics that came up during the week, which proved very helpful sometimes. So what were the goals that we had in mind for KF Six? The obvious one is we want to use Qt Six, but sort of the baseline requirement we're talking here. But we wanted to do more. The perhaps most important goal we had in mind was porting should be as easy as possible. That was a goal for Qt in the Qt Six transition and we wanted to have the same. So no complicated, needless breakage. Breakage should be as obvious as possible and as obvious to fix as possible. Then of course we want to have better APIs, APIs that are easier to misuse, are clearer, have a clear purpose, are not duplicated, are not better served with Qt or the C++ standard library for example. Then a lot of our code is based on Qt Widgets, but we're getting increasingly more Qt Quick and QML code, but some of the frameworks things we have are still quite a bit entangled with Qt Widgets, sometimes in trivial, sometimes in not trivial ways. And we want to have a better separation between the UI agnostic part and the actual UI part so that it's easier to use all of the frameworks things from for example QML. Then another goal we had in mind was reducing the dependencies some of our frameworks have because dependencies are not nice and dragging things along that you don't need is not nice and especially for some things like Qt. This really wasn't a hindrance for third-party developers to actually make use of our nice libraries. Then we also wanted to have a better separation between an interface to something and its implementation. For example, for K Wallet we have an API that the library uses to talk to the password system, then we have the implementation of the actual password system and we wanted to have those a bit separated so that it's easier to for example plug into an operating system's native password storage system like we have on Windows for example. And that ties into the next goal which is better cross-platform support for platforms like Windows, Android, Mac OS or just non-plasma Linux systems. So I've mentioned that I gave a talk at Qt on Brazil last year and they gave me a nice slide template and it had this slide that says as a placeholder, this is a quote, words full of wisdom that someone important said and can make the reader get inspired. And I thought it was a nice idea and I really wanted to have a nice quote for it. But all I could think about was something we kept saying at the last Plasma Sprint in Valencia which is are we there yet? So are we there yet for framework six? The answer is sort of when I was preparing my talk at Qt DevCon, I came up with a handy website that automatically tracks how many of our projects are ported to Qt six by looking at the CI configuration and I called it iskadiusingqt6.org. So if you open that right now, it will tell you that 380 out of 528 projects built against Qt six right now which is most of them for some definition of most but don't read this as a progress indicator. We're probably not gonna ever get to 100% there and that's fine and it's most important we know the blocker for an actual KF6 release. Then earlier this year Plasma and frameworks started relying exclusively on KF6 and Qt six. Previously development has been going on in a way where we build against both at the same time but at some point we said okay, we're going all in on six now, five maintenance continues in a separate branch and that's the situation where we are with frameworks in Plasma right now and it's working out quite well. The Plasma six session is already quite usable. I'm using it right now on this laptop to give you this presentation. I would show you but it just looks like Plasma so not much to see there. We still have a few items on the workboard left. The done column has about 260 tasks out of 400 something but again don't read this as a sort of progress indicator because some of them are more organizational than actionable and some of them are more optional or wish list. But there's still a few challenges for us ahead before we can think about releasing a 6.0 and Falka's gonna tell you all about them. Right, so in terms of things that definitely have to happen before the release I think we have one major thing to sort out and that is the whole coexistence story, right? So we don't only have the luxury situation of Qt six apps in a Plasma six session. We also have Qt five apps in a Plasma six session. Qt six apps in a Plasma five session. We have six apps in non-Plasma sessions right in all possible combinations there. And there is various things that could interfere with that working nicely. The probably most common one is file system collision so just things installing in the same location, right? And that doesn't work. That's usually what is referred to as co-installability but this is only part of the bigger coexistence story. It's the one we ran into during build time which makes this easy to deal with. The other ones tend to be a bit more nasty. Example of this is, for example, Debo service names, right? They have to be unique so we can't have two processes claiming the same name. At the same time we have services that can't just arbitrarily coexist, right? Something like the wallet system. Whether an application can restore its credentials shouldn't depend on whether it's using Qt five or Qt six or running in a matching session, right? That should just work. So there's things that we can't just have in parallel. Another problem area is the whole plugin-based platform integration. So the most visible part of this is typically the style. And right now this problem doesn't even seem that big because the Plasma five pre-style and the Plasma six pre-style are pretty much identical from a visual point of view. But as, like over time we expect the Plasma six style to somewhat evolve and change, right? And a Qt five app running in a Plasma six session should still use the new style, right? So we need that also in a compatible way for Qt five. Same thing with the file system, or the file dialogue integration. You want to use the proper platform file dialogue and not some fallback and all the stuff that pulls in. Similar problem with the generic application plugins. Things like the console part or the ocular part, right? So if you have a Qt five-based Dolphin and a Qt six-based Kate, both of them should still have the embedded console terminal. It shouldn't depend on in which session you're running, which of those will get the terminal, right? And then there's some really dark corners when we get to environment variables set by the session and so on. None of those are usually hard to solve. It's just many of them. And we need to go through all of them and look case by case and how to address them. Typically we have like three different standard approaches that we can apply and in some rare scenarios we might need some special solutions. The probably most common solution is, or approach we take is versioning, right? So this is basically what applies to all the libraries. You just increment the version number and then things can happily live side by side. That's easy on the library side. It requires adjustments to all consumers basically. For libraries, CMAC checks that for us at one time this is a bit more difficult to spot. Especially right now where there is still a lot of five infrastructure around and if I'm still using the wrong DBAR's name for example, I might not notice. So some of this only shows up as we move to a pure six session. Another standard approach is exclusive to it, well, just having one of the things, right? So like in the wallet scenario, right? Then in some cases we need to retrofit built options there to disable stuff in five because we weren't prepared for this and we might need adjustments in packaging but it's generally completely transparent for the consumer side. However, that also kind of implies that we need to stay compatible across major version changes. A very prominent example of that part is also the icon themes. They're very big, right? So we don't want to duplicate them. And there we have the XTG icon spec which defines the compatibility anyway, right? So there is no risk that we, or that we can't break the compatibility anyway, right? So that is an example for using this approach. A much less commonly used approach is multi-builds. So the same code base with a single run of the build system produces libraries for both Qt versions. This is something we haven't historically used in KDE. A prominent example is Poplar, right? That produces Qt bindings for both versions but this has recently been also proposed by David and Harald for example, for phone on and for things like the freestyle that might also be an interesting option. It however requires that the five and six code base kind of stay aligned and it limits our ability to eventually retire the Qt five support, right? If we do this too early, then we basically end up in the same problem again. We can't co-install this. Right, and then we get to the dark corners. When we think about the API, then that is usually like C++, QML, and maybe CMake, right? However, there is more that is de facto API, like the executables we install and their interface and their names or the environment variables or all the stuff we put in debuts. And since we don't really think about this as API, but people use it as API, right? There's some ambiguity on what is guaranteed there and then people get creative. An interesting example we found there is how the KDE session version variable is interpreted. Some users just concatenate that on debuts names or executable names, right? And then basically assume that the same thing will exist with the version six as well. Others just error out. And I mean, this happens in niche applications like Chromium or LibreOffice or things like the XDG Utils, which they do features like basically opening files and URLs on the entire Linux platform, right? So also kind of important or libraries we use like JetKeychain. So we need to identify all of those things also in the external consumers and then see if we can make the new API kind of match their expectation or if we need to fix stuff upstream there now. So it's ready in time when we get to releasing KF6. And yeah, so as I said, this is probably the only really hard blocker. There is however many more things that we still would like to see or even things that are somewhat critical to get done like ECM isn't able yet to build APKs. So that's a pretty hard problem on Android. And there's things we would like to get done in Qo to be able to replace the aging HTTP implementation, for example, and a lot more. But worst case, we'd survive with all of that done for the initial release. If you're interested in discussing those details and working on those details, we have a buff on this Tuesday at four o'clock. We also have another buff on Monday about how you port your applications and that is what Alex is going to talk to you about now. Yeah, thanks Volker. And first of all, we're going to talk about the KDE source build setup for port on your apps. And like always, this utility is your friend and helper when it comes to building KDE software. And it takes care of a few things for the KF6 builds. For example, choosing the correct CMake arguments because in some projects you explicitly need to turn on the KF6 or Qt6 builds. And sometimes you need to disable some deprecated APIs. And it also chooses the correct branches for you. And because projects, for example, Dolphin have a separate KF6 branch. But we'll come to that in a moment. It can also compile third party packages. For example, dependencies that are needed to build other KDE framework or other KDE software in general. And the KF6 builds are configured by the global branch group setting. So it's the global section of your KDE source build config file. And you just need to specify the branch group to the value KF6-Qt6. And then it automatically knows what the correct CMake arguments are and what branch it should check out. But it is recommended to have a separate prefix from your KF5 one because there are still some remaining constulability issues. And apps, for example, Dolphin don't simply need to be fully co-installable. And that is configured using the KDE-DEA variable which is like the install directory and also the source directory and build directory. You could maybe reuse the source directory but that would make the rebuilding process take a lot longer. And you can do this, of course, in your main config file or you can have a separate or custom config file. And you can pass that in using the RC file and argument to KDE source build. But since we are lazy and efficient, it is best to have a simple alias for it and you have a snippet there that just loads it from the KDE-6 folder in your home directory. And that works in both Bash and Fish and maybe ZZ2, but I haven't tried that. So now we can get started on our apps. And the first step as Nico and I told you last year at Academy is to disable deprecated API. But you should really make sure that you are using latest frameworks because lots of API that was removed in KF6 had back-ported deprecation macros and maybe even the alternative API or some porting aid to the KF5 branch. And those are only contained in the later versions. And then you, of course, need to adjust your build system for non-library code. It is recommended to just use the version with CMake targets and that is what we do in Plasma. And for other cases like libraries or frameworks, we need to use the Qt Major version. But in KF6 Master, if you want to call it, we are Qt 6 only. So at least there we don't have to do it. But yeah, you can just inject the Major version using this known CMake syntax for injecting the strings. And you can use it for both the find module calls and when using KF5 targets because we intentionally decided not to have versionless KDE frameworks targets. But you should make sure the Qt version option is included and that is a module from extra CMake modules or ECM. And it is usually included by the KDE installers already. But in case you're getting like weird error messages, keep that in mind. And you can see a really simple snippet on where to use that Major version then. But since doing all of this manual work is tedious, Loror has shared his script for adjusting most of the build system stuff and you can check it out in the KDE Dev Scripts repository. And there's a KF6 folder which contains this build system script. And there are also some other scripts for like porting Kirigami APIs and such. But not all changes can be caught by deprecation macros. For example, changes to virtual methods because they are binary incompatible or classes being renamed or moved. And that is also what was done for the KCMs because we had the KC module class in K config widgets and also in K declarative some other KCM related classes and all of them were moved to KCM utils and had gotten a new name. And those need to be adjusted with a pre-processor macro and in some code you can still, or you can see that there's a Qt version check used but if we only want to differentiate between the five and six version, we can use the Major version directly and don't need to utilize the Qt version check. But QML runtime issues are more difficult to port, especially when they are incompatible with KF5. And it is possible to configure those files using CMake and it has a configure file method that allows you to dynamically inject certain strings and you can then install the generated QML files or include them in your QRC and that is what's done, for example, in Eliza. But depending on the complexity, it is a big hassle like if only a few properties got renamed it is of course doable, often import has changed but for more complex refactorings, it is possible and even desirable to have a separate KF6 branch and that leads to a cleaner code base because you need less compatibility code and you can utilize new features and APIs if you wish but there's also the risk of diversions and you have a bit more maintenance effort and so it also depends on how actively developed your app is if there are still many features being developed or not. And when actually doing the porting since we now know how to proceed and the plugin system is one of the major challenges and in KF6 both the runtime and build time JSON conversion was removed that includes the K plugin metadata from desktop file method and also the K-coordance desktop to JSON CMake function but the desktop to JSON CLI tool which you should use for the manual conversion is still kept and if you're wondering why this doesn't have a major version it was removed in KF6 so we don't have to worry about co-installability and you can use it just from the five K-coordance and when you encounter deprecation warnings regarding the plugin system and the documentation of the API provider or the warnings you get on the console are quite important because they tell you what plugin namespace should be used and the version that the change is compatible with and after the conversion you just need to adjust your macros you can see two of them those are the ones we usually use also the way of determining the plugin ID has changed because previously the ID was often specified in the metadata and in KF6 we only used the base name for it and you also get a warning on the console in case the ID you've specified which is now internally ignored but if that ID is different from the base name and you can just remove it in that case because that is compatible with KF5 and the porting of K service type trader is documented and was already discussed last year and since then there are only a few breaking changes for like in-system providers like the keyword parameter of the K plugin factory create method was removed but that will only affect you in case you have a custom macro for it or you have a custom factory but there are some improvements you can utilize for example the find plugin by ID method has better performance because it can now directly load the plugin from disk and doesn't need to query all the available plugins and that also allows better compatibility in case you want to utilize static plugins and there's now a parameter for allowing plugins with empty metadata and what is most relevant for developers is the operator so you can log a K plugin metadata object directly and here you can see an example on how that would look like the plugin ID and the file name and you can of course benefit from the optimized internals of K plugin factory and K plugin metadata and we would also be very happy to have you at the buffs and yeah, feel free to ask any questions. Are there any questions? Right, I mean for the ocular case I don't think we have a nice solution at this point, right? So the somewhat, well at least part of the idea how we try to minimize the problem is to get as much as possible done for the first release or in a relatively short period of time, right? Because that doesn't solve the problem in a theoretical way but practically the problem is much less likely to occur, right? And maybe then we get away with some of those corner cases then. But yeah, in theory, you would need to co-install ocular in both versions, right? And I'm not sure if we really want to go there. Not necessarily the full ocular, just ocular part and everything that this uses, like some internal ocular but not necessarily two ocular executables. Sure, but I mean this is like 80 or 90% of the code, right? It's duplicate packaging, it's maintaining the pipe thing for some more time, right? Ideally we wouldn't want to do any of that, right? In an ideal world, right? I mean in an ideal world, we just get ported, get everything ported, right, and ignore that problem. So that is, I hope we can do much of that. It's probably to some degree also a case-by-case thing. Ocular is fairly widely used as a part but I think it's manageable to port most or all of the consumers. Then there's stuff like Q extras which we will probably have to ship both flavors off for the foreseeable future because Q is used everywhere and without Q extras Q is not that useful. Yeah, I mean that would break the file dialogues, right? And I mean as long as we have major Qt5 consumers out there like say Twitter, we can't break their file dialogue, so. Okay, so maybe I'm asking a stupid question or misunderstood something but can't you just drop the .QRC files since the new Qt6 CMake API would be if you make a QML module and list the file, the resource files under resources. That's for the QML porting, right? Yeah, again maybe. Yeah, the thing is that we don't use that at the moment and we have our own version of that in ECM it's just called ECM at QML module but in case one needs to inject such compatibility strings using CMake one still has to make sure that the version of the file from the build directory which is configured is picked up. Maybe one can just specify an absolute path in the Qt APIs on the Qt CMake function for that or how is it practically used? Okay, better to wait until Monday I guess. Perfect. I have a question regarding the plug-in thing. I'm sure you have already thought about that but well if you decide to drop the KDE5 plug-in for example for Ocula and replace it with a plug-in for KDE5 that internally uses the KDE6 plug-in. Would something like that work? The main problem there is we can't really have both major Qt versions in the same process. If that would be possible, right? Then a whole lot of those problems would go away but since that doesn't work, right? We can't put this in the same process, right? And then no matter how we try to approach or proxy this that will always end up with both Qt versions in the same process and then you have competing event loops and flashing symbols and it will crash. You can proxy it using Wayland and it's in the process. Right, you would need to put it out of process but then we're getting in a whole new different world of pain, let's just port everything and be done with it, that is a much easier approach. Well actually we can have two Qt libraries in the same, we made that possible for Qt 5 and Qt 4 but it requires that the application that opens the plug-in uses a feature called Deep Link so that the plug-in does its own linking and finds its own libraries instead of reusing those of the host library. Of course you can still don't do anything with dual event loops interface that doesn't use any Qt data structures. Then you can do it because we had these problems that was certain types of libraries that had a plug-in used Qt, so we solved that back in Qt 5 days early. But that is on the symbol level, right? Yeah, that's only if you have an API that Qt interfaces. So it's not that useful for KDE. Like Qt plug-in loader would usually refuse to load any plug-in that was built against a different version, even if it's the same major version. Yeah, I mean, also with stuff like namespacing you could work around the symbol problem, true, but the ocular part is like an interactive thing, right? So there's needs rendering and user interaction and please let's not go there. So I didn't see any date in there? Well, technically there is no date yet, right? So the current preliminary thinking and all of this, right, subject to change. I think that we basically have to go backwards from the Plasma plan for Plasma 6. The current state is still thinking towards end of the year. So assuming we manage that for Plasma, right, then we would need frameworks in say November, which means starting with pre-releases in August or September, right? So this is getting really close then. And then maybe year 2312 would then fall in the same cycle, right, and could contain the first six days, sorry. So I think that that is the best case scenario, like we certainly won't be faster than that. So far, I think we are still on track to make that. If we don't make that right, then it slips by four months or whatever, it's then the next window where we make that. But the plan is basically to follow the Plasma plan and then work backwards from there. Okay, thank you.