 Okay, it looks like we should be starting, so good luck. Thank you. So, I hope all of you know by now that Qt6 is a thing. It was released in the end of 2020, so that year did bring some positive things, at least for us. And if you follow the history of KDE, you know that a new major Qt version has always meant a new major iteration of the libraries and software that underpins all of KDE software. And this time is not expected to be any different. This is both a very challenging and an exciting time. It's challenging because there will be some porting pains, there will be some effort, there will be some kind of breakage. But it's also an opportunity to do things better and do this kind of change that we usually can't do because of some kind of compatibility promise. So, in this talk, I don't actually want to talk about Qt6 very much. Instead of I want that, I want to focus on what's coming on the frameworks and libraries side on our stuff. And in particular, I want to talk about what has happened so far in terms of effort towards a KDE framework 6. I want to talk about all the things that we are planning to do or we are expecting to be done. And I want to focus on some of the underlying goals and design decisions that were made. So my primary goal is that you as an application developer are not caught by surprise when some changes are made. And I want you all to be aware of or roughly aware of what's coming so that you're aware of and can help us actually do it. So the whole effort towards KDE framework 6 started even way before Qt6 was officially a thing. The first time we really talked about it was at Academy 2019 in Milan back then where we like still physically met in a room for Academy. Sounds weird right now. And there we had a framework 6 both. It wasn't a Monday morning, I think 9am after the social event in the evening. So if Qt6 turns out to be a mess, that's why. And at that meeting, we collected some rough design ideas and goals and things that we want to get done for framework 6. But the most important takeaway message from that was we need a sprint to talk all about that. And a sprint we had. In November 2019, some of us met in Berlin for a weekend long sprint about all things Kf6. Now, if you take a closer look at this picture, you will find one person missing that you would very much expect to be at a framework sprint. And that's David Ford. But for some reason, he wasn't able to come to Berlin at that time. So he made a virtual appearance here depicted inside this laptop. We all find that quite peculiar at the time. Little did we know that just a few months later, we would all attend sprints that way. So I guess that's just another example of KDE being ahead of the time. At this print, we talked about design goals and design ideas and principles that we want to apply for this transition. And I'm going to highlight the most important ones. First of all, Qt itself promises that the migration from Qt5 to Qt6 will be a rather smooth one. Not without, completely without a pain, but manageable. And we want to achieve the same. We don't want disruption. We want evolution instead of revolution. And we agreed on a general procedure for making breaking API changes. So if you want to change an API in a breaking way, you should try to introduce the replacement API right now during the lifetime of KF5. Then we start porting all the users of that old API we want to remove to the replacement. And only once all of the significant users are ported, or at least an effort has been made to prove that porting is feasible and that we don't miss any important use case, then we deprecate the old API. And when we are branching for KDE Framework 6, then all things that are marked as deprecated are removed. So we do that because we want to avoid that we as frameworks developers in our ivory tower make some arbitrary decision like, oh, we don't like that API. That's weird. Just deprecate it and get rid of it. But two years from now, some application developer wants to port their application to Framework 6 and they realize, oh, this thing is gone and there's no proper replacement for my use case. So to avoid that, we agreed on this basic principle. That means for you as an application developer, if your project gives you a deprecation warning for something huge or KF5 during the build, then go fix it. Because once you're starting to port to Qt 6 and KF6, this API will be gone. This is your warning. And we try to keep the amount of breakage that cannot be ported ahead of time and can only be addressed while actually porting from 5 to 6 as minimal as possible. But of course, there might be some cases where this is not possible. So we probably can't completely avoid it, but we want to very much keep it minimal. Then of course, we want our APIs to be better. But what does better mean in this context? Sometimes we have API in our frameworks where Qt or DC++ standard library actually has a better replacement. And we want to make use of that where it makes sense and try to remove our own API where it makes sense. Because often the upstream API is equally as good or even better and we want to, of course, use the better thing. And we want to get rid of duplicated things where possible. Because we also try to avoid duplication in our own APIs because duplication makes it harder to maintain. It makes it harder to document. It makes it harder to test. It's confusing. You don't know which one to use and which case. And wherever it makes sense, we try to converge to a single unified API for things instead of duplicated things. Currently frameworks is built on top of C++11. But C++11 has evolved quite a bit since then. Qt6 itself will require C++17. So at least at that point, we need that for our apps as well. But a lot of KDE software actually makes use of C++17 now. And just today, we ported frameworks itself to build with C++17. So C++17 brings, amongst other things, some nice vocabulary types like, for example, is to the optional that help to make better APIs by making them more descriptive, more semantic, and generally easier to understand and use. And we want to make use of that because we want nice APIs. Then the transition is, of course, also the time to address all of those to do KF6 comments that are littered across the code base to fix up all those little API things that we can't fix right now because of strong API stability guarantees. And that's just something that someone dedicated needs to do. And we also want to remove some of the stuff that is not used at all or very rarely used because unused code is untested code and that means it's broken code. And it just increases the overall maintenance burden so we want to remove stuff where it makes sense. Then what we also want as a design goal is a better separation between parts that are Qt Widgets specific, between parts that are Qt Quick specific and stuff that is shared between the two of them. Because right now a lot of our APIs use types from Qt Widgets without actually really needing to. And by doing that, we want to improve the QML compatibility of our frameworks because currently we have some functionality, for example, spell checking via Sonnet that works great for Qt Widgets applications but not for Qt Quick applications. And since the trend goes very much towards writing new software to Qt Quick, we of course want our nice frameworks to work there as well. A common example of this is using a Qt Widget pointer to represent a window that works but it's tied to Qt Widgets. We actually have a common base class that is in Qt GUI and thus works with Qt Widgets and Qt Quick that is Q Window. And by porting stuff from taking a Q Widget pointer to using a Q Window pointer, we improve things. Then what we also want to avoid is having a Qt Quick application and then somewhere, for example, in a file operation an error occurs and KO pops up a Wishit-based dialogue to inform the user that something has gone wrong. That does not look particularly nice, especially it looks really alien on Android. So in order to improve that, we want to achieve a better logic and UI separation so we can plug different UI implementations on top of the same logic. And a very good reason to avoid a Qt Widgets dependency in your Qt Quick application is that it saves your binary size. The Qt Widgets library is something like 5 megabytes in size and if your Android APK is 5 megabytes smaller, that's pretty nice. What we also want to do is reduce the dependencies between our frameworks. What you see on the screen is the dependency graph of KO and the fact that you probably can't really read this graph kind of proves what I'm talking about. We hope that by reducing the dependencies between the frameworks we make things a bit easier to deploy because not all dependencies are easily deployable on all platforms and automating a lot of dependencies that depend on each other is not that easy as it is with just a handful of dependencies with no dependencies themselves. It saves installation size, which is kind of not that much of an issue on the Linux desktop. It can become an issue in embedded deployment. And by reducing the dependency tree, we hope that we make frameworks more attractive for outside users because right now what we often hear is, oh, I don't want this because it drags half of KDE with it, which is of course bullshit, but it's an impression that sticks around. Then we want a better separation between interfaces and implementations. Yes, some frameworks mix the two of them. For example, we have password storage via KWallet. KWallet is both an implementation of a password storage system and an API for applications to use it. But on GNOME, for example, GNOME has its own GNOME keyrings thing. We could use KWallet there. It works because it's just Linux, but it would be much nicer if, for example, Dolphin was running on GNOME, all the passwords would be stored in GNOME keyring. On Windows and Mac OS and Android, KWallet does not really work at all. All of those platforms have some form of native password storage system which we want to use there. It would be nice if we had a single API that applications can use that would then transparently use whatever platform backend is suited best. A similar story is sharing things via purpose. Purpose provides an implementation of shared as file or shared as URL with, for example, NextCloud or KD Connect or some other application. On Linux, that works nice. On Android, the Android system has its own sharing implementation provided by the system which we want to use when running on Android. And here again, it would be much nicer if we had an interface API that allows us to use any of these implementations without actually worrying about it. And also, same story with file indexing, which on Plasma is done by Balu. On GNOME, it's done via GNOME Tracker. Other platforms probably have their own implementations on it of it. And we again want a simple interface to use all of them without needing to worry about them. Somewhat tying into this, we want better cross-platform support for our frameworks because Qt is cross-platform itself. KDE software originally was very Linux-specific but we got a lot better in that regard and lots of our applications do work on other platforms and that's something we want to encourage developers to do. But some of our frameworks could help more with that. First of all, we want this kind of interface and implementation separation that I talked about earlier before. Sometimes we have this separation but an implementation for a specific platform is missing. For example, KeyNotifications does a pretty great job at that because it supports Linux, it supports Android, it supports Windows, it supports macOS but, for example, it does not support iOS. So adding an iOS backend would make KeyNotifications a very attractive thing to use for Qt application developers. Then, as I mentioned, some dependencies are hard or impossible to deploy on some platforms. A common example is D-Bus, which we use for a lot of things on Linux but on Windows and Mac it only kind of works and usually doesn't make sense. On Android it just doesn't work at all. But some of our frameworks use D-Bus in their APIs or have it as a dependency so we want to try to avoid as much as possible to pull in as a dependency on Windows or Android and macOS. That makes it easier to deploy and avoid some failure cases. Similar story with X11 and Wayland which we use directly in some of our frameworks like KeyWindows system. And what we also try to do is identify recurring problems that we have not yet solved in Qt or in KF5 and add new APIs to solve those problems. One thing that comes to my mind is that in a couple of applications we have implementations for inhibiting screen locking and screen time out for various different platforms and it would be very nice to have a single framework to do that so we have a nice cross-platform API. That's not really related to KF6 though, we can add that API anytime we like. Then it's also time to retire some of the frameworks that have served us well in the past but are not really relevant anymore either because they model deprecated concepts built on deprecated APIs or are just not generally useful anymore. First thing that comes to mind is KDE-LIB4 support which was only ever meant to be a porting aid from Qt4 to Qt5 but it's about time we get done with that so there's no need for KDE-LIB4 support anymore then KHTML has served us amazingly well in the past so amazingly that other people picked it up and turned it into something else which ironically we tend to use right now which is Qt Web Engine. Similar story with KDE WebKit and KJS and KJS Embed so they are generally not used anymore we even ported Conqueror away from KHTML so it's time to retire those. Similar story with Cross there's a better replacement for scripting which is QJS Engine and Cross is not really used by much anymore so it's probably time to retire that as well. Media Player and KXML RPC Client were only ever used by two applications for each and those are obsolete as well so since nothing actively maintained use them and nobody maintains them we just should sunset them and then there's KDE in it which is an attempt to speed up application launch times by doing some clever things unfortunately it turned out that in a lot of cases we don't actually make use of them so we did some investigations and some profiling and it turns out these days it's not really useful at all and doesn't really provide an improvement so it should go as well. Then once we had established these design principles we split up in some smaller groups and made a list of all the frameworks and distributed them across the groups and then each group looked at some of the frameworks and evaluated how well they fit the goal and we made some notes on them some action items which we then discussed in a logic group and what we ended up with is a nice big fabricator work board you can find it on that link or search for KF6 it currently contains 384 tasks some of them done, some of them not some of them are more meta tasks or design goals some of them are very actionable some of them need to wait through the KF6 branching a lot of them can be done now so I would like to encourage everyone here to go have a look at that work board and pick up some tasks and help us get them done because the work we're doing right now will shape the future of our software for the foreseeable future so that work is hugely important we also agreed back then on the first sprint that we would like to have a follow-up sprint something like six months later for obvious reasons that did not happen and it was not until earlier this year that we managed to have a follow-up sprint completely virtual of course but that does not mean that nothing has happened in between because a lot of people did what I just encouraged you to they went to the work board, picked up some tasks got them done, discussed more, refined tasks split them out, added new ideas and it was pretty productive and at the second sprint we got together to discuss some of the open questions some of the things that needed input for more people and just refine some of the tasks to be more precise and more actionable and we also agreed that we would like to have some kind of regular meeting to talk about frameworks things so currently every Saturday at 1pm UTC we meet on bit blue button to go over some of the open tasks for an hour and discuss some things where people got stuck and need help or input or discuss questions around that so if you're interested in framework 6 then come join us on a Saturday so now I want to present some of the highlights of the technical aspects that we agreed on or already did this is by no means an exhaustive list of things I just picked some of the things that I consider the most important or most impactful first of all there is the case service type trader class which manages services a service can be a couple of different things it can be an application, it can be a plugin it can be a k part which is mostly just a special case of a plugin it can be a kconfig module which again is mostly a special case of a plugin it can be pretty much anything that is described by a desktop file and case service type trader manages a global database of all the available services you can use it to query that database it's done via some specialized trader language and you can write queries like give me all of the applications that are installed give me the preferred image viewer give me all of the applications that can handle png files give me vk part preferred to open pdf files give me all the plugins for kd connect but as it turns out using that trader language is not very intuitive and people would rather much write C++ codes than some domain specific language because it's much easier to approach and understand and mixing things together that are not really the same like applications and plugins that doesn't really make sense since a couple of years we actually have a new way of querying and loading plugins which is the kpluginloader and kpluginmetadata api and kcore addons and over the years a lot of the plugin stuff was poured to use that and so we agreed that we want to use for all of the plugin loading applications to this new approach then we also got around to have a better replacement for querying applications which is kapplication trader which is pretty much like kserverstep trader except only for applications and instead of a domain specific language we use a C++ function to do arbitrary filtering and you can use that to answer questions like what's the preferred image viewer or give me all the applications that can open PDF files and for kparts we came up with a new kpartloader which is very similar to the application trader just for kparts so you can tell it give me an instance of a kpart that can handle PDF files overall pretty much all of the use cases for kserverstep trader had better replacements so it's natural to just remove the whole thing another framework that is expected to have larger changes is kicon themes in particular we want to remove the kiconloader usage because there is a better upstream API in Qt which is qicon from theme qiconloader and qicon from theme do is you give it an icon name and what you can return is a qicon or a PIXMAP that corresponds to the icon you requested and unfortunately kiconloader has some troubles or it's not that intuitive to use for high DPI scenarios so just by porting from the KDE API to the Qt API there are a lot of high DPI rendering issues which of course is nice then I've talked about kwallet and the interface implementation problem and as it turns out there's already a third party Qt library that does exactly what we need and that is Qt Keychain so what we are planning to do is to acquire Qt Keychain as a KDE framework and use that one as an interface to Kwallet which then becomes an implementation detail and as an interface to all of the other back ends I just talked about last year at academy David Four had a talk about all the new jobs in KIO where he talked about reworking K-run into a couple of new jobs which are application launcher job and command launcher job and those achieve this separation between QWitches part and non-QWitches part and this separation between logic and UI representation much better than the old K-run did so what you can do right now is plug different UI delegates in the same job so you can have a delegate that pops up a Q dialogue we created a new one that pops up a notification which for plan will use cases much nicer and you could write your own thing that integrates into your Qt Quick application and while I was researching this talk I came across an academy talk from 2019 from David Four about the new KDE framework and there he mentioned to remove K-tool invocation this time we really mean it what K-tool invocation does right now is sort of two-fold one use case for it is launching things via KDE in it but as I've mentioned earlier we actually want to remove KDE in it so that API isn't really useful anymore and we should use one of those launcher jobs that I've talked about earlier the other use case is stuff like launching a mail client launching the help center and to do that we are probably going to add some new API on top of the aforementioned launcher jobs so they have a main specific interface and then use the common mechanism to actually launch the job and in order to improve the QML support of the frameworks we want to break up the existing K-declared framework because it's purpose is again a bit two-fold it contains first of all some generally useful Qt Quick and QML related classes like for example all the QML KCMs have a common base class there and it also contains a couple of QML bindings for other frameworks and it turns out that due to all of this the thing depends on KAO which has this horrible dependency tree that you have seen earlier and that makes a very K-declared very not nice to use and people are scared to use it because all of the dependencies it drags in so we hope that by moving all of these frameworks bindings into the respective frameworks instead of having them all in a single framework and by reworking some of the internals to remove the dependency tree a lot and make it more attractive to use and thus improve the QML support of the overall frameworks product again this most by no means an exhaustive list there's still a lot of it going on have a look at our work board join us on for example KDE-Devil to talk about anything you want to talk about and I'm not the end do you have any questions for me? thank you very much Nikolas for that I do see some questions already I can read them for you if you'd like how is KDE handling issues with lack of Qt multimedia until release of Qt 6.2 how will media playback be handled with planned deprecation of K-media player so the lack of Qt multimedia until Qt 6.2 is very easily avoided by just not porting anything to Qt 6 until then because right now the current plan is for Qt multimedia to be released in a couple of months and we still have a lot of work to do before we get to the point where you would actually need Qt multimedia there are still plenty of things to do before that and K-media player is not actually used by anything except one application and that one is pretty dead so there's no issue there okay good to know then someone was confused when you were talking about removing some functions with framework 6 API does it mean they will be deprecated but kept around until framework 7 or how does that work now when I say deprecate things I mean in KF 5 they will give you a deprecation warning and then when we actually get around to making a branch for framework 6 then we delete all the things so everything that's deprecated now will be gone in framework 6 okay then on making things modular is it planned to use optional dynamic library loading with graceful feature degradation if certain libraries example kf crash are not installed on the system we sort of do that already and some places we plan to use a little bit more so one example is kstandard shortcuts which currently lives in kconfig widgets which has a rather not nice dependency tree because it depends on a couple of things and it's actually one of the diverse offenders in the overall dependency tree and kstandard shortcuts and this is kconfig to read your settings from the disk so you can configure your shortcuts and what we plan to do is we take that thing and move it down to kgui addons which cannot depend on kconfig but we actually are planning to add a plugin mechanism so when you run a plasma you can write a plugin that then feeds the configuration information into the library and on non-plasma platforms this kind of configurability doesn't really exist so for example on windows there's no point in trying to read the plasma settings so there it's not an issue or we could write a window specific plugin that records something so that's a pretty neat trick that we try to apply in some places that can help okay thank you very much and still one question here that I see remaining will there be some better documentation for things like plasma applets, desktop widgets, etc in frameworks 6? that's pretty much unrelated to framework 6 because nothing is stopping us from writing better documentation now we don't need to break api to do that one nice side effect of framework 6 is that we are re-breaking some things, removing some things and making some things a bit easier to use without documentation or when replacing things we try very much to add documentation so the overall transition sort of helps in that direction but in general the question of better documentation is pretty unrelated especially when it comes to plasma things that are even more unrelated to frameworks okay so basically you can do better documentation right now and stopping us so I'm glad that I was pushing for better documentation by having higher two people to work on that because it's certainly an important thing yeah I agree okay I don't see any other questions Nicolas thank you again very much are there any other tags or buffs that you will be handed? I think there will be a kf6 buff I don't know when it will be but I trust you to find it on the wiki people can surely find it in their schedule okay thank you Nicolas