 I'm sure we're going to hear his voice and see his face. Hello. Take it away, Volker. Yesterday, Alex and Mikro showed you how you can call to Framework 6. So you basically had slightly less than 24 hours to actually apply that. So time to look at how much progress we have made. Before we get to that, quickly, how all of this started. Three years ago, last in-person academy, we set out to do the transition to Q6. And one important decision there was that we want to keep the time we spent in branching as short as possible. Because branching, there's basically two options for this. Either we split our workforce in two, do five and six in parallel, which means we'll have a lot of cost in merging and stuff being done twice or getting lost and so on. So that's not ideal. So before we jump with everyone on the six-based branch, and then that will probably take months until in which we are not able to deliver many updates to our users, that's also not ideal. So inside the idea was to do as much as possible in the Q5-based code bases, keep them in a releaseable state tonight, so it won't impact any of that, and then do the branching as late as possible and as short as possible. That also requires that larger changes that we can only do after branching should be prepared as well as possible so that we don't find to do QAKF6 redesign this like six weeks before we want to release. Another important part is the leave-no-module-behind idea. So if we do larger changes in frameworks, significantly change or remove an API, for example, the idea is to adapt as many as possible of the consumers of that right away so that we don't three years down the road realize that as a use case we miss or something isn't as easy and obvious to transition as we originally saw. I mean that is the reason why we still now have KTLyps 4 support users and we wanted to avoid that right from the start. So let's see where we are and I was only half joking about how recent changes are here. The slides have some very last-minute patches but they are probably still outdated again. At this point, all non-deprecated frameworks are building on Linux, FreeBSD and Android and more than 50% are building on Windows as well and especially the last number has been going up steadily in the last couple of hours. And by building I not only mean works on somebody's machine with some modifications, no, that is actual CI coverage and that also means with working unit tests. The vast majority of unit tests produces the same results as with Qt5 already. There are still individual ones that need to be sorted out. Beyond frameworks, we also have the platform integration bits of Plasma working which is the exception of the global divorce menu stuff which means you get proper styling, proper prior dialogues, etc. Looking at applications, if we have a widget application and you manage to get that to build, it is very likely to just work. And not just the simple stuff, we have seen parts of contact with Akronagi integration working. You can use Cate already to edit itself, all of that works fine. German is a bit more complicated, not so much because it requires more complex changes but because we can't if they're there but instead we have a conversion script that you need to run and that does 80% of the changes and then you're also able to get to something working there. All of that, as I said, happened in the Qt5 code bases during ongoing releases. There have been some minimal disruptions as is expected for this, right? This is three years of a large team effort but on the other hand, we also have discovered problems, for example, by being able to already use the district of type checking in Qt6 right now. So, then let's actually look at stuff running. Okay, so let's start with Cate that I already mentioned. The differences are so small that the only thing I can actually show you to prove that it is actually Qt6 as the version number in the APALT dialog, otherwise it looks exactly the same. So, let me try something else, also pretty much the same thing here, it just works, it looks exactly the same but it is running on Qt6, so let's try something QML based, so this is Gerigami Gallery, it can show a version number, so you have to trust me that this is also running on Qt6. It looks like the Qt5 version, it has all the correct styling and it just works. Let's do something slightly more complex and hybrid, that might be the second try, another one. There we go, system settings and again, this has a version number I can show you, there we go, this is also running on Qt6, in fact the entire shell you'll see here with all the usual plasma stuff and the QIN session it's running in is all running on Qt6, there's actually no Qt5 left here. So yeah, we have made quite some progress to manage the expectations a bit, that is not the out-of-box experience, that requires some local modifications running the QML conversion script and so on to get there, but nevertheless it is much further ahead than we were, I mean prior to branching already compared to what we had in past major version transitions. There are still a few things left to do before we can branch, that list is also rapidly shrinking, a couple of days of the right people and I think we can get that sorted out, which brings us to the interesting questions on how to proceed, when and how to branch, what to branch, so what is the scope of the first six-phase release, is that just frameworks, which is the easiest to achieve but relatively useless, or frameworks and plasma or parts of plasma, so that needs to be discussed, we have an off for that tomorrow at 3pm, and that is not just for framework developers, that is explicitly for all the framework consumers because this is about decisions that affect all of us, and as we want to keep the branch lifetime as short as possible, that means that the time window for getting larger changes done is rapidly closing, so if you still have stuff that you want to see done, that is probably also something we are discussing. See you tomorrow at the booth and let's sort all of this out.