SUMMARY This bug is part of an ongoing effort to rethink the options available in System Settings. The end goal is to consolidate some obscure options to make Plasma feel simpler to use and improve the user experience. I was advised to make individual bug reports with my suggestions. More details with all the suggestions and talking points can be seen in this shared document: https://collaborate.kde.org/s/oEkdeYerKqaZNyC ------- The Magic Lamp / Slide effects offer the option of changing the animation speed independently of the global option. This creates an inconsistency in the user experience because not all effects have that setting. While one might think that that means all effects should also have that option, having too much granularity in the settings can create an inconsistent experience and make Plasma feel more difficult to use, while also increasing a higher number of untested configurations and bugs. I propose removing those options and only allowing users to control the animation speed globally. Removing it also means removing the entire settings window for the Magic Lamp, thus effectively simplifying System Settings a bit more. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.24.80 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.13.0-28-generic (64-bit) Graphics Platform: Wayland Processors: 6 × Intel® Core™ i5-9400F CPU @ 2.90GHz Memory: 7,6 GiB of RAM Graphics Processor: Radeon RX 570 Series
Yep.
>The Magic Lamp / Slide effects offer the option of changing the animation speed independently of the global option. Just to clarify it is not independent. A factor of the two values is used.
I guess the reason for those independent duration settings was that the magic lamp and slide animations interrupt workflow. The overall animation speed might be nice, but maybe you don't want to wait a second for the desktop to switch or a window to be restored. At least I don't want to, so I now had to set global animation speed to almost instant, because the choices available for the desktop switching animation also lack "none". Huge improvement!
(In reply to Sebastian E. from comment #3) > I guess the reason for those independent duration settings was that the > magic lamp and slide animations interrupt workflow. The overall animation > speed might be nice, but maybe you don't want to wait a second for the > desktop to switch or a window to be restored. At least I don't want to, so I > now had to set global animation speed to almost instant, because the choices > available for the desktop switching animation also lack "none". Huge > improvement! The user already has the option of disabling those effects entirely if they interrupt their workflow, so, for that usecase, the setting to independently control animation speed is redundant.
After last update the slide effect is crowing. The last few pixels to scroll is taking too long. It is indeed affecting my workflow. When looking closely now I can see it is likely related to some unrelated bug or regression related to two monitor setup and the slide effect. As now any window spawning both monitors has half of it invisible unless the effect is completely finished. Giving the impression I'm block until then. But eitherway I ended up here when I was trying to find how speed the slide effect up as a workaround. I don't remember if the option was there before. I used to use the Cube effect before it was removed. Just wanted to say, please don't remove customization options/possibilities. That has always been selling point of KDE. To consolidate and simplify the experience perhaps makings sensible defaults would be better? Or implementing profiles/config-sets which would apply multiple options at once.. I also don't want to turn the effect off. Since it is giving me important visual feedback helping me realizing I'm switching the context.
(In reply to Premik from comment #5) > After last update the slide effect is crowing. The last few pixels to scroll > is taking too long. It is indeed affecting my workflow. > When looking closely now I can see it is likely related to some unrelated > bug or regression related to two monitor setup and the slide effect. As now > any window spawning both monitors has half of it invisible unless the effect > is completely finished. Giving the impression I'm block until then. > > But eitherway I ended up here when I was trying to find how speed the slide > effect up as a workaround. I don't remember if the option was there before. > I used to use the Cube effect before it was removed. > Just wanted to say, please don't remove customization options/possibilities. > That has always been selling point of KDE. To consolidate and simplify the > experience perhaps makings sensible defaults would be better? Or > implementing profiles/config-sets which would apply multiple options at > once.. > > I also don't want to turn the effect off. Since it is giving me important > visual feedback helping me realizing I'm switching the context. The bug that is causing you to have to change the speed of the effect as a workaround is what should be fixed instead. Adding workarounds to bugs in the interface is not optimal. Now, about defaults, can you explain what defaults are you talking about? The default is to follow the global animation speed setting, which is user configurable. What default should be changed here in your opinion? As for the config presets, I don't see how that would help in this case. The point of presets is to quickly change frequently adjusted settings. Individual animation speed is not something the user will change often. Also, there is a big number of effects, so presets couldn't possibly cover all possible combinations of speed settings for each effect. Also, using a preset for each individual effect is no faster than changing the global animation speed slider. Please mind you the point of this bug report is NOT to remove options simply for the sake of removing options. Yes, simplification was used as one of the points for this bug report, but what's really important in this case is how controlling the same setting in multiple places adds to complexity, increases the number of untested configurations and bugs, and also leads to an inconsistent user experience. I'll give you an example: Just recently it was discovered that the blur effect suffers from a similar issue, where disabling the blur effect doesn't disable it in multiple parts of the interface simply because some effects override the blur settings individually, just like the effects here override the global speed setting. Overriding global preferences in individual effects creates problems. It should also be noted that the majority of people will never customize individual animation settings, and even you only found out about that possibility because you needed to work around a bug, otherwise, you'd have never tried to customize that setting. The drawbacks are too big to justify the minimal amount of granularity this offers.
Premik said that the last pixels take too long to scroll. That's the effect of easing, not a bug. The animation slows down towards the end. Windows that overflow to another screen are indeed invisible on that screen during sliding, which is a bug. The defaults Premik is talking about are obviously the easing mode and the duration of animations relative to each other. Now the slide animation takes a hardcoded factor x as long as some other animation. Before, you could at least change the speed of the slide and magic lamp independent of the speed of other effects. Now, the ratio is hardcoded. That's clearly a regression, and yet another step from a sophisticated, un-opinionated DE to a dumbed-down, opinionated DE. Users should be able to override the easing mode and duration of each animation individually. @Premik: The configuration dialog of the slide effect used to have an option for the animation duration, which was removed from the latest release. Maybe you once changed it and forgot about it.
(In reply to Sebastian E. from comment #7) > Premik said that the last pixels take too long to scroll. That's the effect > of easing, not a bug. The animation slows down towards the end. Windows that > overflow to another screen are indeed invisible on that screen during > sliding, which is a bug. > > The defaults Premik is talking about are obviously the easing mode and the > duration of animations relative to each other. Now the slide animation takes > a hardcoded factor x as long as some other animation. Before, you could at > least change the speed of the slide and magic lamp independent of the speed > of other effects. Now, the ratio is hardcoded. That's clearly a regression, > and yet another step from a sophisticated, un-opinionated DE to a > dumbed-down, opinionated DE. Users should be able to override the easing > mode and duration of each animation individually. > > @Premik: > The configuration dialog of the slide effect used to have an option for the > animation duration, which was removed from the latest release. Maybe you > once changed it and forgot about it. The easing curve was never configurable, and the magic lamp effect still allows for a custom duration. >Windows that overflow to another screen are indeed invisible on that screen during sliding, which is a bug. I urge Premik to file a bug report about windows disappearing if that wasn't done already. The problem here is what was quoted above. >Now the slide animation takes a hardcoded factor x as long as some other animation. Before, you could at least change the speed of the slide and magic lamp independent of the speed of other effects. Now, the ratio is hardcoded. If there's a problem with the animation itself, then that should be fixed instead of leaving it up to the user to work around the issue by manually speeding up individual animations or manually choosing the easing curves. Mind you easing curves don't usually change the amount of time it takes for an effect to complete, only the speed of movement within a certain timeframe, so changing it wouldn't have any effect on the amount of time it takes for windows to appear after the animation starts.
(In reply to guimarcalsilva from comment #8) > If there's a problem with the animation itself, then that should be fixed > instead of leaving it up to the user to work around the issue by manually > speeding up individual animations or manually choosing the easing curves. > Mind you easing curves don't usually change the amount of time it takes for > an effect to complete, only the speed of movement within a certain > timeframe, so changing it wouldn't have any effect on the amount of time it > takes for windows to appear after the animation starts. The problem with the slide animation itself is that it's too slow. Sure, I could increase the global animation speed, but then all other animations would be too fast. Of course, that's just my opinion. How to fix that? Hmm... how about providing an option to control the speed of the slide animation independently from all other animations? Oh, it already existed, but was removed, because it was inconsistent? Well, then how about providing that option for every animation? That would make everyone happy, and emphasize KDE's selling point of being an un-opinionated, customizable, powerful desktop environment, instead of undermining it.
(In reply to Sebastian E. from comment #9) > (In reply to guimarcalsilva from comment #8) > > If there's a problem with the animation itself, then that should be fixed > > instead of leaving it up to the user to work around the issue by manually > > speeding up individual animations or manually choosing the easing curves. > > Mind you easing curves don't usually change the amount of time it takes for > > an effect to complete, only the speed of movement within a certain > > timeframe, so changing it wouldn't have any effect on the amount of time it > > takes for windows to appear after the animation starts. > > The problem with the slide animation itself is that it's too slow. Sure, I > could increase the global animation speed, but then all other animations > would be too fast. Of course, that's just my opinion. How to fix that? > Hmm... how about providing an option to control the speed of the slide > animation independently from all other animations? Oh, it already existed, > but was removed, because it was inconsistent? Well, then how about providing > that option for every animation? That would make everyone happy, and > emphasize KDE's selling point of being an un-opinionated, customizable, > powerful desktop environment, instead of undermining it. The right thing to do here is to fix the speed factor of the animation in the code so it has the same speed as all other animations. If it's too slow compared to everything else, then that's the problem. Leaving it up to users to fix problems is not good for anyone. Anyway, the default animation speed for that specific effect is another bug and should be discussed in bug 455450 , not here.
(In reply to guimarcalsilva from comment #10) > The right thing to do here is to fix the speed factor of the animation in > the code so it has the same speed as all other animations. If it's too slow > compared to everything else, then that's the problem. Leaving it up to users > to fix problems is not good for anyone. Anyway, the default animation speed > for that specific effect is another bug and should be discussed in bug > 455450 , not here. There is no objectively correct speed factor. It's subjective and thus must be a configurable value.
Just found this bug report after looking for bugs related to long animation durations when switching activities since 5.25. The animation duration of the slide effect seems to be used when switching activities, which is painfully slow. Changing the global animation speed doesn't do anything, but disabling the slide effect does. The slide effect seems to hardcode animation times: https://invent.kde.org/plasma/kwin/-/blob/6af5a5e65112d9b24392efd6be461d3b85c1ef86/src/effects/slide/springmotion.cpp https://invent.kde.org/plasma/kwin/-/blob/6af5a5e65112d9b24392efd6be461d3b85c1ef86/src/effects/slide/slide.cpp#L62-63
>The slide effect seems to hardcode animation times: Please reread your second link.
My animation scaling factor currently is 0.7: ``` $ grep AnimationDurationFactor ~/.config/kdeglobals AnimationDurationFactor=0.7071067811865475 ``` Dividing the *constant* value of 200 by the animation duration factor ``` 200.0 / effects->animationTimeFactor() ``` means that the faster I want my desktop's animations to be (lower animation duration factor values), the slower the slide animation will be. And if I set the animation speed to "instant", which means an animation duration factor of 0, kwin crashes because of a division by zero.
>means that the faster I want my desktop's animations to be (lower animation duration factor values), the slower the slide animation will be. No, because it's not a duration. It's this "springiness" constant. >means that the faster I want my desktop's animations to be (lower animation duration factor values), the lower the springiness is, making it faster. >kwin crashes because of a division by zero. That's valid, lets fix it
> No, because it's not a duration. It's this "springiness" constant. Okay, but you have to acknowledge that with the addition of the "springmotion" logic in 00ae7d38939e3e0c3414009f49d1dabb3a6345bd, sliding between desktops and switching activities has become painfully slow, especially the last end of the animation, which is a usability nightmare. Compared to other animations controlled by the global animation scaling factor, the slide animation is about twice as long, which is really bad. The constants either need to be adjusted accordingly, so that the overall animation time matches the one of the previous implementation, or the user should be given a chance to customize them.