Move KCMs in "Workspace Theme" to more appropriate locations
ClosedPublic

Authored by ngraham on Jan 20 2019, 9:23 PM.

Details

Summary

This is patch one out of three in support of the new Appearance section layout in Plasma 5.16 decided upon on in T8871: Systematic KCM reorganisation.

In this patch, KCMs are moved out of the Workspace Theme category, and the ordering of some KCMs is changed accordingly. The now-empty category gets deleted in D18417.

Test Plan

Diff Detail

Repository
R119 Plasma Desktop
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
ngraham created this revision.Jan 20 2019, 9:23 PM
Restricted Application added a project: Plasma. · View Herald TranscriptJan 20 2019, 9:23 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ngraham requested review of this revision.Jan 20 2019, 9:23 PM
ngraham edited the summary of this revision. (Show Details)Jan 20 2019, 9:25 PM
ngraham retitled this revision from Adjust some KCMs to implement new Appearance section layout [1/3] to Adjust some KCMs to implement new Appearance section layout.Jan 20 2019, 9:30 PM
davidedmundson requested changes to this revision.Jan 20 2019, 10:04 PM
davidedmundson added a subscriber: davidedmundson.

We have all agreed before that we will not do any top-down shuffling until all the work updating KCMs bottom-up has been completed. It's documented in that linked thread. That ground-up work has not finished.

This revision now requires changes to proceed.Jan 20 2019, 10:04 PM

That's true, and we discussed this a lot in the VDG channel. The problem is that such a condition will in practice result in delaying this re-ogranization practically indefinitely.

https://phabricator.kde.org/tag/plasma_kcm_redesign/ lists 42 KCMs that require porting (44 if you count the ones with "kinda done" in the title). That's an enormous amount of work. The 5.15 Plasma release contains one ported KCM. Say that we focus all of our resources on this and port five KCMs per plasma release, that's still delaying this for nine Plasma releases, or over three years. ...By which time, Qt 6 will have been released and probably a good chunk of our efforts will be on porting to Qt 6 rather than porting KCMs. The re-org will just never get done.

I don't see what harm it does to implement the parts of this re-organization that don't require merging KCMs. Once all the KCMs are ported, we can do those merges at that time, right? For example probably Emoticons will be collapsed into Icons, GTK Application Style will be collapsed into Widget style, and so on. In practice I don't see how those kinds of merges would be harmed by doing this re-organization for Plasma 5.16.

abetts added a subscriber: abetts.Jan 20 2019, 11:16 PM

I am not opposed to a reorg as long as it doesn't touch the KCMs, but be aware that you "might" have to reorg again as we port KCMs. So, do you prefer to do it, potentially twice, or just once?

To clarify one thing, I didn't say "porting". The original task was to go through all of them unifying them, rethinking design and following Fabian's new HIG as well as making sure all options are in the right place, etc.. I personally don't particularly care too much which tech is used.

From that POV there are waay more changes this release, especially Björn's work with the title casing.

It seems like it'll require enormous amounts of work because enormous amounts of work are the only thing that will deliver anything with any substance.

I don't see what harm it does to implement the parts of this re-organization

It breaks existing user habits as well as breaking every manual/documentation/help post on the internet.
Obviously that has to happen occasionally, but it's not a move to be done lightly.

I'm trying to get a sense of when we should do this.

  1. Improve text on existing QWidgets KCMs to conform to the HIG
  2. Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG
  3. Port all QWidgets KCMs to QML
  4. Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

Between which items should this re-org be located?

abetts added a comment.EditedJan 25 2019, 3:16 PM

I'm trying to get a sense of when we should do this.

  1. Improve text on existing QWidgets KCMs to conform to the HIG
  2. Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG
  3. Port all QWidgets KCMs to QML
  4. Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

    Between which items should this re-org be located?

I my mind, it would be #5 since we know that through the porting and improvements we make to the kcms, we end up making them look vastly different, in some cases. This makes it so that a KCM doesn't really belong to the same category anymore. We also discovered that we have a few KCMs with just a couple of options that would make them move to a new category. That would change the organization again.

This would be my preference. However, if the wave is to reorganize right now, then I lean towards small reorganizational changes, a piecemeal approach and not a huge revamp right out of the gates. That way we can be sensitive to our users that need to adapt to progressive reorganizational changes.

Thanks @abetts, I appreciate the support, but I feel like it should not be for the reason that "the wave is to reorganize right now". This has nothing to to with popularity or momentum; it's because the reasons previously given for waiting wait are not valid. We cannot spare our users from churn and incremental changes that break muscle memory and invalidate documentation because we lack the resources and long release cycles necessary to do the one thing that would avoid that: making all changes in the span of a single release. Because we don't have that option, we are *already * doing those things every time we port KCMs one-at-a-time, change strings, even improve icons! Waiting for the re-org on the grounds that we want to avoid burdening our users with constant change things does not make sense because we are already doing this with every release. In fact, there is no option not to; our fast release cycles and limited resources make it impossible.

I do agree that it's important to make the minimum number of changes to avoid jerking users around and keep the churn as low as possible. However that's not an argument for waiting years and years to do this (or anything), it's an argument for ensuring that we make high-quality, well-considered changes that do not need to be reverted later. I encourage anybody who's nervous about this to participate in T8871: Systematic KCM reorganisation, which is where we're coming up with the plan. The more people who participate in that process, more the conclusion will reflect a consensus view that avoids controversy and and the impulse to redesign--which are after all signs and symptoms that the original design was not good enough.

I'm trying to get a sense of when we should do this.

  1. Improve text on existing QWidgets KCMs to conform to the HIG
  2. Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG
  3. Port all QWidgets KCMs to QML
  4. Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

    Between which items should this re-org be located?

I my mind, it would be #5 since we know that through the porting and improvements we make to the kcms, we end up making them look vastly different, in some cases. This makes it so that a KCM doesn't really belong to the same category anymore. We also discovered that we have a few KCMs with just a couple of options that would make them move to a new category. That would change the organization again.

You're debating me on something I am not suggesting. I am not saying "stop reorganization, do it only just once". I am saying, let's take a piecemeal approach, little by little (which is our only option, really) and let users be eased into a new organization. I hope that's clear. What I am also saying is that it is best to take this reorganization piecemeal approach right now and come to a conclusion with it. One that can last for years. In essence, take the step by step reorg now. However, once we complete that work, we should hold off from reorganizations afterwards.

That's good to hear! I'm glad we're on the same page. Let's make sure our plans in T8871: Systematic KCM reorganisation reflect the consensus of a diverse set of opinions so we don't wind up needing to re-do it in the future.

That's good to hear! I'm glad we're on the same page. Let's make sure our plans in T8871: Systematic KCM reorganisation reflect the consensus of a diverse set of opinions so we don't wind up needing to re-do it in the future.

Great! :D

Improve text on existing QWidgets KCMs to conform to the HIG

After this.

Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG

After this.

Port all QWidgets KCMs to QML

I don't especially care, though it's often the most effective way to do the previous step. It's an effort to compromise. If I had wanted to block this forever, I would be insisting on this.

Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

This is by /far/ the most important step to do before shuffling top levels about. Otherwise you don't know what we're shuffling.

GB_2 added a comment.Feb 2 2019, 9:06 PM
This comment was removed by GB_2.
GB_2 added a comment.Apr 8 2019, 6:15 PM

Improve text on existing QWidgets KCMs to conform to the HIG

After this.

Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG

After this.

Port all QWidgets KCMs to QML

I don't especially care, though it's often the most effective way to do the previous step. It's an effort to compromise. If I had wanted to block this forever, I would be insisting on this.

Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

This is by /far/ the most important step to do before shuffling top levels about. Otherwise you don't know what we're shuffling.

All Appearance KCMs are polished and conform the HIG now.
We have a plan here: T8871
I think we should go ahead with this now.

In D18419#446142, @GB_2 wrote:

Improve text on existing QWidgets KCMs to conform to the HIG

After this.

Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG

After this.

Port all QWidgets KCMs to QML

I don't especially care, though it's often the most effective way to do the previous step. It's an effort to compromise. If I had wanted to block this forever, I would be insisting on this.

Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

This is by /far/ the most important step to do before shuffling top levels about. Otherwise you don't know what we're shuffling.

All Appearance KCMs are polished and conform the HIG now.
We have a plan here: T8871
I think we should go ahead with this now.

@davidedmundson do you approve?

From my last comment

Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

This is by /far/ the most important step to do before shuffling top levels about. Otherwise you don't know what we're shuffling.

GB_2 added a comment.Apr 9 2019, 4:11 PM

From my last comment

Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))

This is by /far/ the most important step to do before shuffling top levels about. Otherwise you don't know what we're shuffling.

But we know what will be merged and it won't make a difference for this layout: T8871

  • KDE & Qt Applications + GNOME & GTK Applications
  • Emoticons + Icons
GB_2 added a comment.Apr 14 2019, 2:19 PM
This comment was removed by GB_2.
GB_2 added a comment.Apr 24 2019, 4:30 PM

Should we really wait until those are merged and not have the new layout in Plasma 5.16? Merging these will take quite some time and I don't see how it would make a difference layout-wise.

davidedmundson resigned from this revision.Aug 1 2019, 3:48 PM

My opinion on top-down "lets shuffle things" remains the same.

However, I am happy to approve iterative changes. I can see how this is a prerequisite to renaming "Workspace Theme" which seems to make sense, given it's not under the group workspace, and we're sending mixed messages.

I don't object to this particular patch.

ngraham updated this revision to Diff 62909.Aug 1 2019, 3:55 PM
ngraham retitled this revision from Adjust some KCMs to implement new Appearance section layout to Move KCMs in "Workspace Theme" up one level.
ngraham edited the summary of this revision. (Show Details)
filipf added a subscriber: filipf.Aug 1 2019, 4:56 PM

+1 regarding the Cursor Theme and Plasma Theme, but it doesn't make sense to me that Splash Screen will be in Appearance, while Login Screen (SDDM) will be in Startup and Shutdown.

I'd put Splash Screen into Startup and Shutdown, it's a distinctly startup thing. My just be my 2 cents, but I also don't consider it that important (=often changed) of a setting that would warrant putting it somewhere close to the top and being top level.

+1 regarding the Cursor Theme and Plasma Theme, but it doesn't make sense to me that Splash Screen will be in Appearance, while Login Screen (SDDM) will be in Startup and Shutdown.

I'd put Splash Screen into Startup and Shutdown, it's a distinctly startup thing. My just be my 2 cents, but I also don't consider it that important (=often changed) of a setting that would warrant putting it somewhere close to the top and being top level.

I guess we have a small conflict then when something is both purely appearance-based, but also fits into multiple categories. The Splash Screen, Plymouth, and the SDDM KCMs all fit the bill. My gut tells me that you're right and all three should live in Startup and Shutdown just based on frequency of use.

ngraham updated this revision to Diff 62914.Aug 1 2019, 5:22 PM
ngraham retitled this revision from Move KCMs in "Workspace Theme" up one level to Move KCMs in "Workspace Theme" to more appropriate locations.

Put the splash screen KCM in {Startup and Shutdown}

ngraham updated this revision to Diff 62916.Aug 1 2019, 5:28 PM

Don't change "Plasma Theme" string

ngraham edited the test plan for this revision. (Show Details)Aug 1 2019, 5:29 PM
filipf accepted this revision.Aug 1 2019, 5:33 PM

+1 regarding the Cursor Theme and Plasma Theme, but it doesn't make sense to me that Splash Screen will be in Appearance, while Login Screen (SDDM) will be in Startup and Shutdown.

I guess we have a small conflict then when something is both purely appearance-based, but also fits into multiple categories. The Splash Screen, Plymouth, and the SDDM KCMs all fit the bill. My gut tells me that you're right and all three should live in Startup and Shutdown just based on frequency of use.

Yeah, it can fit into multiple categories and we don't have usage data, but I would bet they don't get interacted with as much as Appearance KCMs.

This revision was not accepted when it landed; it landed in state Needs Review.Aug 1 2019, 5:37 PM
This revision was automatically updated to reflect the committed changes.

but it doesn't make sense to me that Splash Screen will be in Appearance, while Login Screen (SDDM) will be in Startup and Shutdown.

The problem that needs resolving there is SDDM KCM also does autologin and configuring UIDs to list.
So you have a split between functional and appearance in one KCM.

It's the fundamental problem with most our KCMs - we group at a top-level by category, but internally KCMs individually are grouped by code location. Whilst we have that state, no top-level is correct and no moving will fix it.

It's why there is a rule (which still remains!) stopping moving KCMs about at a top level without first doing any of the useful work that needs to happen from the bottom up inside the KCM.