Create Task
Maniphest T13663

Changing the colors in a color scheme requires a kconf update script to perform the migration for users
Closed, ResolvedPublic
Actions

Description

When a user switches their active color scheme, the colors KCM writes the new colors to the user's kdeglobals file, from which they are read by other apps.

This presents a problem when VDG wants to change the colors of any of the default themes we ship: doing so does not update any of the colors in users' kdeglobals files until the next time they switch color schemes and then go back to one of the default ones.

We can mitigate this by writing a kconf update script every time we update one of the shipped color schemes, but this is a pain in the butt. It also does not work for color schemes that users get from store.kde.org; when they get updated, there is no way for the colors in users' kdeglobals files to get refreshed to match the new ones.

Is there a technical reason why we need to continue writing colors into the kdeglobals file rather than just specifying the name of a color scheme and having that color scheme's file get read as needed?

If that's not changeable, could we maybe have kded or something else get notified when the colors in the scheme file change, so it can update the colors in the kdeglobals file? Or if that's impossible, could we refresh the colors in the kdeglobals file on login if there are any differences between the ones in the config file and the one in the color scheme itself?

ngraham created this task.Sep 17 2020, 9:26 PM
ngraham renamed this task from Make it easier to change to Changing the colors in a color scheme requires a kconf update script to perform the migration for users.
ngraham updated the task description. (Show Details)Sep 28 2020, 6:03 PM
davidre added a subscriber: davidre.Oct 2 2020, 11:46 AM

The histrocial reason is that you could change the color scheme and the changes were written to kdeglobals. But now we only allow modifying color schemes that are writeable so both should be in sync if you change colors/edit schemes now. (Please correct me if I'm wrong, @broulik)

But there can be cases where kdeglobals and .colors file are currently not in sync because it was changed before the above. For the future (KF6/Plasma6?), I agree and would like to do away with the exported colors in kdeglobals. That means doing away with every client code that reads i which is basically KColorScheme. But there is probably also some code out there that reads colors directly from kdeglobals. (Note: that means we now need to read two config files instead of one to read the actual colors).

Anyways this doesn't seem like a super pressing issue given that it has happened now once at the end of the lifetime of Plasma5

ngraham added a comment.Sep 17 2021, 7:59 PM

Here's something we could perhaps do in the meantime: re-serialize the color data to kdeglobals on plasmashell startup if color data is missing or differs from what's in the config file of the active color scheme. This would also fix https://bugs.kde.org/show_bug.cgi?id=384950.

ngraham added a comment.Sep 17 2021, 8:00 PM

Anyways this doesn't seem like a super pressing issue given that it has happened now once at the end of the lifetime of Plasma5

In addition to causing https://bugs.kde.org/show_bug.cgi?id=384950, this issue also causes pain every time colors in the color scheme are fixed or updated; users don't see the changes until we tell them to manually switch to another color scheme and back to the original one again.

davidedmundson moved this task from Backlog to Requires KF6 on the Plasma 6 board.Mar 5 2022, 4:54 PM
ngraham closed this task as Resolved.Nov 4 2022, 2:16 PM
ngraham claimed this task.

This was fixed a while ago.