Changed from a 6-step slider to a 10-step slider.
Speed factor from
{ 0, 0.2, 0.5, 1, 2, 4, 20 }to
{ 0, 0.2, 0.5, 1, 1.25, 1.5, 1.75, 2, 2.5, 3, 4 }20 is too slow and isn't very useful. So I dropped it. 4 is a good maximium value: it looks very slow but still acceptable.
Between 1 to 4, here are 5 more ticks, so users can control more detailed speed. It is
the range that makes most difference.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 56 | |
| Build 56: arc lint + arc unit |
| kcmkwin/kwincompositing/compositing.ui | ||
|---|---|---|
| 24 | Seems like it's unrelated change. | |
| kcmkwin/kwincompositing/compositing.ui | ||
|---|---|---|
| 24 | I edited this file with Qt Designer and it automatically added these lines. I could revert them if not wanted. | |
| kcmkwin/kwincompositing/compositing.ui | ||
|---|---|---|
| 24 | Yes, please. | |
| kcmkwin/kwincompositing/compositing.ui | ||
|---|---|---|
| 120 | Please add this one back. | |
| kcmkwin/kwincompositing/compositing.ui | ||
|---|---|---|
| 120 | Done. | |
This would break configurations of users.
Also I don't think that such a change is needed as I already expressed in the bug report. It is possible to adjust the speed on a per effect level. I doubt that any user would benefit from a higher granularity.
If users' configuration is one of 0, 1, 2, 3, it won't change anything. If users' configuration is 4, 5 or 6. It only get slightly faster, nothing break.
That means it breaks. It's a change to their configured setting and this is the definition of breakage.
Every software update do changes to the behavior of software. Change !== Break. All software may introduce changes that affects current configurations. For example, KDE's default wallpaper will change with each release. It doesn't mean that all this kind of changes should not happen.
Considering most users are using default value (3), only a few users will notice that change. I guess nobody uses the value 20, which is extremely slow. For users, it is easy to change the settings and get similar effect as before.
We don't break users configuration. There is nothing which justifies that. For example: if the user configured a wallpaper the new wallpaper won't replace it. Only default values my be modified by updates. As soon as a user configured a setting it must not be changed. Users need to be able to trust their software.
We btw have a mechanism to transform configurations. But as I said I don't think all of that is needed. I understand that you want this functionality and it's great that you implemented it, but I very much doubt that it is an improvement for the overall userbase. Due to the fact that the values are no longer balanced I think this degrades the overall user experience.
| options.cpp | ||
|---|---|---|
| 1127 | Before the normal value was in the middle. Now it is not centered any more. I think this is a very confusing user interface for users now. Furthermore please leave the value 20. It's an important debugging feature. | |
If here is a mechanism to transform configurations, I can implement it. If each configuration has a metadata of which KDE version it is for, it should be easy to do. Could you provide any documentation or source code examples of that kind of configuration migration? Thanks.
| options.cpp | ||
|---|---|---|
| 1127 | I can adjust the values so they are centered and keep value 20. | |
If there is a mechanism...
https://techbase.kde.org/Development/Tools/Using_kconf_update
But if we're going to do any migration, I have a proposal that's a tiny bit more work, but IMHO better long term:
Lets store the factor in the config.
It would also tie in a lot better with proposed suggestions to sync kwin and plasma animation speeds, something that's rather awkward with kwin's current rather arbitrary "3" for standard.
The KCM can still show a discrete slider, it's just changing the underlying data storage if we're going to change it anyway.
Thanks for the information. I agree that it is more reliable to store actual value (factors) used by kwin instead of slider scaled value. Maybe in future here will be a dropdown or number input box instead of slider. Configuration UI may change a lot. But stored configuration value should not be affected.