 There was one time where animation in Plasma were so slow for one month, just one month, and it was actually done on purpose. It was not a bug. You would expect me to have somebody to blame for this, but actually I can't really blame anybody. This was actually introduced by a patch by Nate, who also wrote a very useful blog post explaining all of the situation, and the issue really arises from different release schedules in KD Plasma and KD Frameworks. So I'm also going to address that, and actually let me start from that because I also talked about this in this morning podcast, Linux Daily. So this is the patch that I'm talking about. You can see that it is to Plasma Framework. So let's start with a bit of context. What is Plasma Framework? And in general KDE has the KD Frameworks, which are all of the libraries which KDE applications and KDE Plasma use to implement a variety of stuff, which is not directly implemented in KDE Plasma and the KDE Apps, but since it is used in many apps or also KDE Plasma, it is separated into a framework. It is like a set of libraries that expand on the functions of Qt. So one of the things that Plasma Framework does as an example is it has the Plasma theme, the one that defines the appearance of actually the panel, the applets, and this kind of stuff. So it's pretty important. Plasma Framework is one of the KDE Frameworks, and it is the framework that actually contains the Plasma theme, obviously. Also there's a difference to be explained. There's Plasma and there's Kuri Gami. So what is Kuri Gami very quickly? It is a library to make applications that are convergent. So you can use them on mobile, but you can also develop for application on desktop. As an example, system settings, it is partly Kuri Gami. Discover is Kuri Gami and so on. Many new KDE applications are done with Kuri Gami. Now lastly, let's talk about animations. So animation are defined, animation speed is something that you can actually control. You can make it faster and slower. And in general, KDE has some set animation lengths that are used as a reference. As an example, a long animation should always last, I don't know, one second and a half. Just an example. I don't actually remember the exact time. But it has a set time for short animations, very short animations, medium animations, long animations, and very long animations. And we have some milliseconds to describe all of them. Now this is implemented both in Kuri Gami because apps need animations. It's also implemented in the plasma framework so that all applications that use this plasma framework can define animations. And as an example, plasma shell, everything in plasma shell going from the animation that actually opens up kickoff as an example, the length of the animation is based on this base unit, which is medium animation, long animation, I don't remember which one exactly. Okay, so this is the context. So where does the issue start off? It starts off when people realize, Nate realized, I guess somebody realized, but Nate realized that the Kuri Gami units and the plasma units for the animation lengths were different. A short animation in Kuri Gami was different compared to a short animation in plasma. Long animation in Kuri Gami was different. And the plasma animations were actually the baselines for the plasma animations were actually very, very fast. The short one, I think it was like 24 milliseconds, which is way too few. You don't even see it. So every time that you actually did an animation in the plasma desktop, you would say, okay, take a short animation time, the baseline, multiply it by 10 so that you can actually see it. That is a very bad way to approach things, obviously. And it doesn't really make sense to have very short baselines if you always multiply them for some constant. So what's the idea? The obvious fix is to make sure that Kuri Gami and plasma animation times are the same, the baselines. And you also need to remove all of the multiplied by five occurrences in the code. So that's just what's done. This is the patch that actually makes the animation's length just the one that are in Kuri Gami. And it's a very simple patch. It also introduces the very long duration, which was in Kuri Gami, but not in the plasma framework yet. So simple patch. Where's the issue? There's quite some issue. This is because plasma framework is a KDI framework. And the appearances of the application that actually used the plasma framework baseline times to define the animation times were not in the KDI framework, but were KDI apps and mostly KDI plasma. One is KDI plasma released every four months. KDI frameworks, KDI frameworks, sorry, is released more often because, you know, it's the frameworks. Everybody uses them. It has to be very often. And it's released at a different time compared to KDI plasma because why, why is that? Well, it's because KDI frameworks are not meant for KDI plasma. Like they're not designed around KDI plasma. They're designed for any apps, even third party apps that want to use them. So it's not necessarily related to KDI plasma schedule. So this means that this was actually shipped and see here in the blog post in KDI frameworks 5.70, which was a month before plasma 5.18. Now you might start to see the issue. The changes that actually made the animations much longer are in plasma framework. The changes that remove the multiplied by five in the code every time we use a plasma animation baseline are in KDI plasma, which is released one month after the KDI frameworks, which means that during that month there is this change in that makes animation longer, but we don't yet have all the changes that removed and multiplied by and constant, which means that they're super long. And okay, this could have been addressed in a couple of weeks, one of which they're very nicely explained here. By the way, if you want to wear the blog post as well, but the major thing that could have been done is instead of shipping in KDI frameworks 5.70, we could have shipped them in KDI frameworks 5.71, which was just a few days before KDI plasma 5.18, which means, yes, you still have a few days of plasma being slow, but just a few days, right? What's the issue? Well, we have no guarantee that plasma 5.18 were depended on KDI frameworks 5.71 in all distros. There could be some distros that decides to package KDI frameworks 5.70 with KDI plasma 5.18 and not KDI frameworks 5.71. And it's not an art dependency, so we couldn't guarantee that KDI frameworks 5.71 would be in all distros that have plasma 5.18. Whereas KDI frameworks 5.70 was for sure in all distros with plasma 5.18. So KDI frameworks 5.70, it is, and there's also really no way in QML, because all of this is QML, to actually check which version of the KDI frameworks you are in and change the or the opposite for the KDI frameworks to check what version of plasma and change make the animations shorter for plasma so that it's not slower. No way to do that either, which means that we just, KDI just had to accept the fact that it was going to be very slow for one month between the release of KDI frameworks, which fixes the animation times and the release of plasma 18, which actually uses the correct animation times. And that's really it. And one thing that I want to say is that congrats to stuff like ARC, which actually made a patch for plasma workspace to quickly fix that, because the fix was already present in plasma workspace, which is the KDI plasma-related repository, but you know it was going to be released with plasma 5.18, which is one month later. But ARC quickly took that patch and gave it immediately. That was very nice of them. And also, this is not the only time that something like this has happened. Many times, every time there's something in KDI Plasma and KDI frameworks that has to happen at the same time, we just can't guarantee that, which means that if there's appearance change, that's usually in KDI frameworks for KDI Plasma, because the Plasma theme is in KDI Plasma. And if you need something in a KDI framework, sorry, and if you need something KDI Plasma to be sure that you have the newest frameworks, well, you're just going to have to ship that in the next release after the frameworks. And there's always a time between the release of the frameworks and of Plasma. And we just can't avoid that. It also happens the other way around. You should always wait for the next release of the frameworks after a KDI Plasma update to be sure that everything is there. I mean, it's not necessarily usually it's in stuff frameworks releases before KDI Plasma, but still it has happened in the past that some change that was meant for a KDI Plasma release got into the following KDI frameworks one. So this is really weird. One way to fix this would be to align KDI frameworks to KDI Plasma, but that's not a path that apparently wants to be both. Developer doesn't seem to want that. I don't know why I'm not an expert in these things. You could make, move some stuff from the Plasma framework to KDI Plasma like the Plasma theme. Again, that has its own issues as the Plasma theme is used not just by the Plasma desktop, but also Plasma mobile, big screen and outlets, these kind of things. They all use the Plasma theme. So it makes sense to talk for that. So it is kind of complex issue to address. And in this case, right now, the only solution is to accept that sometimes when there's a change that requires both changes from KDI Plasma framework and Plasma desktop, we're going to have that one month of awkwardness. Yeah.