KDE Frameworks 5.70 was just released and should be trickling out to users of rolling release distros at any time. Various Arch users who have already received the update have been complaining about slow animations in Plasma, and I wanted to write a blog post to explain what’s going on here. It is a bit technical so let me start with the TL;DR version: “releasing software is complicated and this will be fixed once Plasma 5.19 comes out next month.”
—
For the longer version, allow me to explain:
This is caused by an unfortunate timing problem stemming from the different Plasma and Frameworks release schedules.
Plasma and Kirigami-based apps use standard duration values for animations (e.g. units.shortDuration, units.longDuration, etc.) to keep animation timings relatively consistent. These duration values are set in the respective Frameworks: plasma-framework and kirigami.
I recently discovered that Plasma units were far shorter than Kirigami units. For example a Kirigami units.longDuration unit is 250ms, while a Plasma units.longDuration unit was 120ms–over two times faster. A Kirigami units.shortDuration unit was 150ms, while a Plasma units.shortDuration unit was 24ms–almost too fast to see. In practice the Plasma units.shortDuration value was useless and always had to be multiplied by something. Even most of the longDuration values were being multiplied by random numbers too. So we wound with animated transitions throughout Plasma having timings like units.shortDuration * 4 or units.longDuration * 3. It was a classic problem of badly-chosen library constants that force apps to work around them and munge them this way and that, totally defeating defeated the purpose of using standardized values in the library in the first place. There was not actually any standardization at all!
I needed to fix this as a part of my introduction of a new animation-using component, the ExpandableListItem (which I keep meaning to blog about): https://phabricator.kde.org/D28033
I fixed the Plasma units to be the same as the Kirigami units in https://cgit.kde.org/plasma-framework.git/commit/?id=0739113a4477e1eb25bf13b0040af5a502d3ef0a, and then fixed Plasma itself to no longer multiply the units in a series of other commits. However this presented an issue: Plasma and Frameworks have different release schedules! So people will not get both aspects of the change at the same time! This means that for a time, some people would have animations that were undesirably slower or faster. How should this be handled?
Unfortunately there is no easy way to do conditionals depending on a frameworks version in QML code as we can in C++ code, so that easy option was not available. Probably something to look into implementing.
So we had a few options. One was to avoid solving the problem until Plasma 6, several years in the future, at which point we could do everything at once. This was not deemed satisfactory, as the issue was blocking the ExpandableListItem patch which was needed for a task targeted for Plasma 5.19. Another option was to leave the existing units alone for Plasma 5, and add new units with different names now, and have Plasma 5.19 use those new differently-named units. This would have avoided the issues you’re all experiencing, but would have resulted in terribly confusing code. In the end we decided to spare ourselves the potential for new bugs stemming from that.
The final option was to wait to make the Frameworks change in a Frameworks release that lines up as closely as possible with the Plasma 5.19 release. Plasma 5.19 depends on Frameworks 5.70, but always releases about a month later, at which point Frameworks 5.71 will be out. This option therefore presented two sub-options: put the units change in Frameworks 5.70 or 5.71?
If we did it in 5.70, there would be a one-month period in which people using rolling release distros suffer from slow animations, because they have Frameworks 5.70 but not Plasma 5.19 yet.
If we did it in 5.71, the period of time in which people suffered from this issue would still exist, but it would potentially be shorter. However depending on distro release schedules, if a distro released Plasma 5.19 *before* Frameworks 5.71, then animations would become too fast to see! Furthermore, any discrete release distro in the future that shipped Plasma 5.19 with the 5.70 Frameworks version it depends on rather than a newer one would then have all of its users suffer from the bug forever (or at least until its packagers backported the plasma-framework commit).
So shipping the units change in Frameworks 5.71 did not seem to be a realistic option. In the end I shipped the units change in Frameworks 5.70 knowing that rolling release distro users (myself included) would suffer from slow animations for one month. Sorry. đŸ˜¦ It will all be fixed in Plasma 5.19.
Software is complicated!
Adventures in Linux and KDE 
awesome explanation, thank you so much.
LikeLike
What is wrong if animations are too fast to see? They are not functional. Personally, I always turn them off.
LikeLike
Animations are in fact quite functional: usability studies show that they help most users contextualize things that appear rapidly, actually increasing their reaction times.
Nevertheless, if you’re not one of those people and don’t like them, you’re more than welcome to turn them off, in which case this transition period shouldn’t affect you at all.
LikeLike
> Animations are in fact quite functional: usability studies show that they help most users contextualize things that appear rapidly, actually increasing their reaction times.
If the reaction times are increased, they were probably disoriented by the animation. But I guess intended to write that reaction time was decreased.
I’ve searched for papers supporting this claim and read a handful of abstracts, but did not find any usability study that supports this claim.
LikeLike
Its worth mentioning if Arch users found enough offense with this they could just revert the frameworks change for a month, its one commit. You can even get plasma-frameworks-git and in a one liner revert it.
LikeLike
It is fixed now in Arch. I open a bug mentioning this post (https://bugs.archlinux.org/task/66607) and maintainer of KDE packages included a patch to modify the times in Plasma (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/plasma-desktop&id=40aca74f5fae265030cfa9a1cc5d07893b219d13). So no need to wait till Plasma 5.19.
LikeLiked by 1 person
Hi, can you please explain how to apply this patch in Arch?
LikeLike
Thanks for the information Nate,
Hopefully the error mentioned will be solved in a short time. I wouldn’t even know about this mistake if you didn’t mention it. Because; I couldn’t see a difference đŸ™‚
LikeLike
Talking about animations, the Emoji Picker application has a super strange (and unnecessary) in the sidebar when the application opens.
LikeLike
Sooooo.. In Kubuntu 20.04 this will be fixed: Never? ..or will it ever even be an issue..? Damn, it just came out and already feels like it got dumped by the road while all the cool cats ride on.
LikeLike
Kubuntu 20.04 doesn’t have Frameworks 5.70, so it’s not affected.
LikeLike
Can’t we just switch the durations based on the import version? Bam, no need for any breakages.
LikeLike
Um … no animation is objectively better than one that is too long. This is just objectively true.
LikeLike
Why don’t release 5.70.1 right with plasma 5.19 or plasma 5.18.1 with frameworks 5.70? Since this is just a matter of constant values it shouldn’t be a problem.
LikeLike
Not that I really care about such issue, but couldn’t you do a pointrelease for Plasma 5.18 to fix that and release it with framework?
LikeLike
Wow, Nate, awesome and in really deep-detail explanation. I, personally, think i’m not suffering this, because i’m not the kind of user who wants any animation (i personally consider them quite useless, but i read your comment above and i can understand that it’s a matter of UX, so of course, it’s its sense, no problem by my side).
I can’t wait any more to receive Plasma on my rolling release distro, Wayland improvements, redesigned/revamped GUI/UI, fantastic. I really want to have it already, (I know the beta has been released, and thanks to our fantastic KDE maintainer/packager i could install it, but i rather prefer to wait for stable release, sorry about that).
I really love your clarity, transparency and your hard work always, this post much more technic is of my like, too.
As always, i would like to thank you very much for your hard and dedicated work, huge efforts and everything you do for all of us, all the KDE Community and all the KDE Software, you really rock a lot Nate :).
Receive a huge, warm and virtual hug dear mate, i really hope you, all your closer environment and in general, all the KDE Community, devs, contributors, translators, writers, UX experts, UI, coders, folks in general, are good too, theirs and their closer environment too, of course.
We’re all in this together, and together we’ll prevail overcome it ^^.
LikeLike
Thanks for the explanation.
Personally, I would’ve preferred a situation where animations were too fast rather than too slow. Frankly, I’ve heard *many* complaints about animations taking too long or being too slow in my years, but cannot recall a single instance of the opposite (ie, animations being too fast).
LikeLike
Perfect! We will wait. It’s a little sad, but we’ll be alive to live.
LikeLike
I’m on plasma 5.19 and frameworks 5.71 with Qt 5.15 (KaOS distro), and i’m suffering a lot of animations issues.
Any time something is requiring lots of update, like an animated systray icon, or plasma notification with delayed auto close, the shell lag / freeze a lot. To a point where i can’t even see the animation at all. This is quite visible by dragging a small window during animations.
It’s quite weird because I have a super fast computer. Note that the issue is more problematic when using latte-dock, to the point i just want to trash plasma / kde as it render the experience annoying in my daily usage.
Do you think it could be tied to this changes or it’s just another issue ?
LikeLike
That sounds like a separate issue.
LikeLike
Hi Nate,
Thank you very much for the thorough explanation.
How can I apply this patch (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/plasma-desktop&id=40aca74f5fae265030cfa9a1cc5d07893b219d13)?
LikeLike
I really appreciate your great work, thanks a lot for that!
> Software is complicated!
While this statement is generally true, in this case the problem is self-imposed. There is no one forcing us to separately release Frameworks and Plasma.
The advantages of separate releases might be larger than the disadvantages, but it would still be possible to have some synchronized releases, i.e. the Plasma release dates on a subset of the Frameworks release dates, e.g. having a combined Plasma and Frameworks release on the same day every half a year and having some intermediate Frameworks releases in between two of these combined releases.
LikeLike