Adjust some KCMs to implement new Appearance section layout
Needs RevisionPublic

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

Details

Reviewers
davidedmundson
Group Reviewers
VDG
Plasma
Maniphest Tasks
T8871: Systematic KCM reorganisation
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, the ordering of some KCMs is changed, a few are moved out of the Workspace Theme category, and some names and comments are changed.

Test Plan

Diff Detail

Repository
R119 Plasma Desktop
Branch
appearance-section-layout-changes (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 7359
Build 7377: arc lint + arc unit
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.Wed, Apr 24, 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.