[kcm-colors] Do not ship any additional color schemes
ClosedPublic

Authored by filipf on Jun 9 2019, 8:11 PM.

Details

Summary

This patch removes the extra color schemes we have been shipping for quite a while. Reasoning is explained in Phabricator task T10497.

Test Plan

delete the contents of usr/share/color-schemes/

Diff Detail

Repository
R119 Plasma Desktop
Branch
no-more-extra-color-schemes (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 12611
Build 12629: arc lint + arc unit
filipf created this revision.Jun 9 2019, 8:11 PM
Restricted Application added a project: Plasma. · View Herald TranscriptJun 9 2019, 8:11 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
filipf requested review of this revision.Jun 9 2019, 8:11 PM

+1 in principle.

I think two things need to happen before we do this:

  1. 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
  2. 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.
nicolasfella added a subscriber: nicolasfella.EditedJun 10 2019, 1:07 PM

What will happen if the user has one of those color schemes active and upgrades Plasma?

That was actually going to be my next question. :) Yes, we'll need to gracefully handle that case too so people don't just get their color scheme changed from under them.

Have you tested what happens when a user is using this theme and we remove it?

We /might/ be ok in this case, as it copies data to kdeglobals.

abetts added a subscriber: abetts.Jun 10 2019, 2:33 PM

+1 on principle. Many of these color themes are old and unmaintained.

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.

+1 in principle.

I think two things need to happen before we do this:

  1. 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
  2. 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.

Yeah, uploading to the KDE store is a must.

I'll try to whip up a patch for the previews to show titlebars then.

filipf added a subscriber: broulik.Jun 10 2019, 4:09 PM

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.

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

File a sysadmin task for that.

All of the color schemes deprecated here are now in the newly-created repo:

https://invent.kde.org/kde/kde-vdg-extras/tree/master/deprecated/plasma-desktop/kcms/colors/schemes

... and on the KDE Store:

https://www.pling.com/u/kdecommunity/

ngraham accepted this revision.Jun 24 2019, 1:49 PM

Tested removing the color schemes on disk and re-adding them from the new items you created on store.kde.org and everything worked perfectly. Let's do it.

This revision is now accepted and ready to land.Jun 24 2019, 1:49 PM
This revision was automatically updated to reflect the committed changes.