Bug 408836 - Data loss: update to plasma 5.16 overwrites task manager settings
Summary: Data loss: update to plasma 5.16 overwrites task manager settings
Status: RESOLVED UNMAINTAINED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager widgets (other bugs)
Version First Reported In: 5.16.0
Platform: Other Linux
: NOR minor
Target Milestone: 1.0
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-17 16:07 UTC by Christian (Fuchs)
Modified: 2019-09-27 21:06 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian (Fuchs) 2019-06-17 16:07:36 UTC
SUMMARY
When updating plasma from 5.15 to 5.16 the configuraton of (icon only) task manager is ignored/overwritten

STEPS TO REPRODUCE
1. Use plasma 5.15
2. Use (icon only) task manager
3. Use some custom settings, such as do not hide windows from other virtual desktops and do not change window on mouse wheel scroll
4. Update to 5.16

OBSERVED RESULT
Configuration is ignored / overwritten. Task manager will filter based on virtual desktop and enable mouse wheel switching

EXPECTED RESULT
User configuration is respected and kept

SOFTWARE/OS VERSIONS

Verified with icon only task manager on both Kubuntu (Disco) and Gentoo, same behaviour.
Comment 2 Eike Hein 2019-06-17 16:21:30 UTC
> this should not have overwritten custom settings though

It wouldn't override a custom setting, but as a default change it does affect existing installations.

It's probably that one.
Comment 3 Christian (Fuchs) 2019-06-17 16:25:48 UTC
In case of the filter it's a bit tricky, since users then unexpectedly don't see windows they opened, so they might consider that a bug and not a setting they would search for. 

A bit meta and thus slightly off-topic for this report: if it was a default change (I think I remember filtering per VD already having been the default, but I might misremember) then the old topic of what to do with these comes up again, since we can't determine whether the user liked a default and thus will dislike or be confused by a change. So it might be worth exploring the option of not overriding settings, even if the default changes, on updates. Of course that would require saving the setting, even if it was the default, which imho makes sense.
Comment 4 Christoph Feck 2019-07-03 11:33:03 UTC
> Of course that would require saving the setting, even if it was the default, which imho makes sense.

Would blow up configuration files if we write out default settings. We should only change default settings if we are sure that the new defaults improve user experience, and then it makes sense that all users see the new defaults.
Comment 5 David Edmundson 2019-09-27 21:06:58 UTC
Given this has been and past, I am going to close it. Sorry. Any migration or fix now would be meaningless and worse introduce a second round of breakage.

It is problematic when we change defaults. There's no universal right answer of whether things should change or not when a user hasn't changed things from the default of the time.