This patch removes the extra color schemes we have been shipping for quite a while. Reasoning is explained in Phabricator task T10497.
- Group Reviewers
- Maniphest Tasks
- T10497: Clean up the default color scheme selection
- R119:b137ee56fa66: [kcm-colors] Do not ship any additional color schemes
delete the contents of usr/share/color-schemes/
+1 in principle.
I think two things need to happen before we do this:
- We need to upload the old ones to store.kde.org, preferably under a shared VDG account so that they can't just randomly go away if whoever uploads it leaves KDE or deletes their account or something
- The preview should show the active titlebar color or else it's really not at all obvious what the difference is between Breeze and Breeze dark. This is a pre-existing problem, but it would become worse when there are only four color schemes shipped by default and two of them have a preview image that looks identical.
The first time I compiled this I actually forgot to clean up the color-schemes folder and nothing happened, the patch didn't delete the old schemes. That's why I concluded it would only be relevant for new installs. I will check again though.
Yeah, uploading to the KDE store is a must.
I'll try to whip up a patch for the previews to show titlebars then.
I ran this test:
- compiled plasma-desktop, master version
- applied this patch and compiled again
- // color schemes were not deleted
- compiled breeze
- // same result
Let me know if this isn't the best of methodologies and how to do more tests.
As for having titlebar color in the preview, I poked around and it seems it's not that trivial. I'm not seeing a way to access titlebar color through model.palette. Tagging @broulik, he might know.
Just recompiling from source doesn't delete files on disk. However distro package managers do. So to test a change that removes files, you need to remove them on disk yourself to simulate what will happen when users update their systems.
Then they'll be removed it seems.
Kdeglobals does save the color scheme in use, and updating wouldn't change it to something else. It wouldn't, however, leave the color scheme in the KCM:
It's good that the active color scheme is saved on disk somewhere (unlike the wallpaper, see https://bugs.kde.org/show_bug.cgi?id=408223), and it's also nice that the KCM is smart enough to handle this case. The wording on that error message could maybe be improved, but that's not a big deal.
Neato, I say we move forward with the prerequisite subtasks. We really should have a "KDE VDG" store.kde.org account or something that we can use as a semi-official repo of created-by-KDE-but-not-shipped-by-default stuff. Maybe what we should make do it create a new repo (kde-vdg-addons?) that can act as a home for this content, which then gets mirrored/uploaded to store.kde.org. The repo should have a CMake file set up in such a way that it's really easy to turn on or off different bits of content. This way it would be available via GHNS, and also vis distro packaging for easier inclusion in distros that want to ship some or all of this stuff by default.
Or maybe that's way too complicated and some random person should upload it. :p
No, that definitely sounds like the right approach. It would also allow us to have an official channel through which we could offer bleeding edge design experimentation.
I don't know how to go about setting a new repo, but with this being targeted for 5.17 we have some time to set things up.
All of the color schemes deprecated here are now in the newly-created repo:
... and on the KDE Store: