Marco is of the mind that we should hold off on doing work on this at the moment. We should hold off until the KCMs have been completely ported. The reason is that we have redesigned each KCM, we have discovered, implemented, and corrected past behaviors that would categorize some KCMs in different ways. Because that work is not complete, I also agree that we should skip this task until later.

I suggested this on the VDG Telegram chat and @ndavis agrees:

"=" is used for section headers
"-" is a level in the sidebar
"( Foo | Bar )" is used for settings tabs

Appearance
==========

- Global Theme

- Desktop Environment
-- Plasma Theme
-- Cursor Theme
-- Desktop Wallpaper
-- Splash Screen Theme

- Applications
-- Application Theme ( Qt Theme | GTK Theme )
-- Window Decorations ( Theme | Button Layout )

- Icons
-- Icon Theme
-- Emoticons

- Colors

- Fonts
-- Fonts
-- Font Management

In case it's not clear,
Global Theme = Look and Feel
Plasma Theme = Desktop Theme

My suggestion was (supported by @rooty):

Appearance
- Theme
- Plasma
- Applications
- Window Decorations
- Splash Screen
- Icons
- Cursors
- Colors
- Fonts

Pros: one-level structure, to me, gives a lot more clarity than nested menus (like Applications -> Application Theme). Putting Applications as opposed to Workspace, and then separating Colors even further aside would personally confuse me if I were exploring the Settings.
Also, I think it'd be a positive change for Plasma Mobile, as mobile users will have real trouble understanding theming as we have it now.
Hopefully, it'll also be easier to choose icons for these sections, as we currently have some weird matches (e.g. Application Style — LnF / "Global" theme).

Possible cons: it shifts the perception of LnF packages to be actual complete themes, and the rest — bits and pieces. IMO it's positive, but only if we stick to it as an ecosystem object. Currently there aren't many complete LnF packages, their functionality is unclear. Maybe, on the other hand, there'll finally be more of them if we perform this change.

@GB_2

BTW, I chose that syntax format so that it could be turned directly into a formatted post on Phabricator:

Appearance

• Global Theme

• Desktop Environment
  • Plasma Theme
  • Cursor Theme
  • Desktop Wallpaper
  • Splash Screen Theme

• Applications
  • Application Theme ( Qt Theme | GTK Theme )
  • Window Decorations ( Theme | Button Layout )

• Icons
  • Icon Theme
  • Emoticons

• Colors

• Fonts
  • Fonts
  • Font Management

In T8871#173013, @IlyaBizyaev wrote:

My suggestion was (supported by @rooty):

Appearance
- Theme
- Plasma
- Applications
- Window Decorations
- Splash Screen
- Icons
- Cursors
- Colors
- Fonts

Pros: one-level structure, to me, gives a lot more clarity than nested menus (like Applications -> Application Theme). Putting Applications as opposed to Workspace, and then separating Colors even further aside would personally confuse me if I were exploring the Settings.
Also, I think it'd be a positive change for Plasma Mobile, as mobile users will have real trouble understanding theming as we have it now.
Hopefully, it'll also be easier to choose icons for these sections, as we currently have some weird matches (e.g. Application Style — LnF / "Global" theme).

Possible cons: it shifts the perception of LnF packages to be actual complete themes, and the rest — bits and pieces. IMO it's positive, but only if we stick to it as an ecosystem object. Currently there aren't many complete LnF packages, their functionality is unclear. Maybe, on the other hand, there'll finally be more of them if we perform this change.

Another con is that a single level means a lot of used up, unscrollable, horizontal space in Icon View.

This is roughly how much space the single level structure would take:

In sidebar view, it's not as bad because it's scrollable, but it would still take up a lot of vertical space:

In T8871#173017, @ndavis wrote:

Another con is that a single level means a lot of used up, unscrollable, horizontal space in Icon View.

Icon view is not supposed to be horizontally scrollable, but it can move icons to next row when necessary.

In sidebar view, it's not as bad because it's scrollable, but it would still take up a lot of vertical space.

Agree here. Still don't think making the features visible is bad, as long as it improves discoverability and understanding. On mobile, "User Preferences" and "Network" sections are key anyway, and "Appearance" section can be safely collapsed (on Android, for example, there's no such group of settings at all!).

In T8871#173013, @IlyaBizyaev wrote:

My suggestion was (supported by @rooty):

Appearance
- Theme
- Plasma
- Applications
- Window Decorations
- Splash Screen
- Icons
- Cursors
- Colors
- Fonts

I really like this. The single-level hierarchy is simple and effective. Are you proposing merging the three Application-specific KCMs into one though? And moving Font management somewhere else? What about the Emoticons KCM? It's pretty useless, but still where should it go?

In T8871#173043, @ngraham wrote:

I really like this. The single-level hierarchy is simple and effective.
Are you proposing merging the three Application-specific KCMs into one though? And moving Font management somewhere else?

Too much merging of clearly different types of settings would be a reason for me to be opposed to having a single level.

What about the Emoticons KCM? It's pretty useless, but still where should it go?

Yeah, I've always wondered why we have this. Most of the time, you need to install an emoji font to get emojis to actually work. Maybe it could be turned into an emoji font selector? Something we currently lack is a way to specify which emoji style to use. I really dislike when I see a mix of color and monochrome emojis or seeing emojis that I know could be colorful fallback to monochrome for no good reason. This may be getting off topic though.

In T8871#173043, @ngraham wrote:

Are you proposing merging the three Application-specific KCMs into one though?

Window decorations I separated; for Qt and GTK I'm not sure, it feels like they can be merged (on my 15'' screen most space's taken by stretched combo boxes).

What about the Emoticons KCM? It's pretty useless, but still where should it go?

I think it can become a tab in icons, we have 2 tabs there anyway

And moving Font management somewhere else?

Oh, font management I've missed... Maybe having 2 KCMs inside "Fonts" as we have now is ok... Or it could be a tab in Fonts since font configuration and font management is essentially the same... Not sure how far we can go with tabs though, and whether this will have to be reconsidered on phones.

In T8871#173055, @IlyaBizyaev wrote:

In T8871#173043, @ngraham wrote:

What about the Emoticons KCM? It's pretty useless, but still where should it go?

I think it can become a tab in icons, we have 2 tabs there anyway

I think this is not a good way to organize them. There's no pattern behind the choice to tie the 2 together other than the desire to put everything on one level. They mostly have no relation to each other except that the emoticons KCM lets you choose a set of images.

In T8871#173056, @ndavis wrote:

There's no pattern behind the choice to tie the 2 together other than the desire to put everything on one level. They mostly have no relation to each other except that the emoticons KCM lets you choose a set of images.

Hmm, you seem to put emoticons to icons, too, so what's the difference?

In T8871#173057, @IlyaBizyaev wrote:

In T8871#173056, @ndavis wrote:

There's no pattern behind the choice to tie the 2 together other than the desire to put everything on one level. They mostly have no relation to each other except that the emoticons KCM lets you choose a set of images.

Hmm, you seem to put emoticons to icons, too, so what's the difference?

There's a bit more separation between them when they're in different sections vs different tabs. Tabs suggests they should be directly related (see Power Management->Energy Saving for an ideal use of tabs).

Conceptually, the reason why I'm in favor of a single-level Appearance section is because a lot of the individual KCMs defy easy categorization, so if we want to maintain the two-level hierarchy, we will be debating forever what goes where. A single level eliminates the issue.

So for the appearance category, here's my proposal:

Appearance
==========
- Global Theme
- Plasma Style
- Application Style
- Fonts
- Icons
- Colors
- Cursors
- Window Decorations
- Splash Screen

In T8871#173101, @ngraham wrote:

So for the appearance category, here's my proposal:

Appearance
==========
- Global Theme
- Plasma Style
- Application Style
- Fonts
- Icons
- Colors
- Cursors
- Window Decorations
- Splash Screen

+1

In T8871#173099, @ngraham wrote:

Conceptually, the reason why I'm in favor of a single-level Appearance section is because a lot of the individual KCMs defy easy categorization, so if we want to maintain the two-level hierarchy, we will be debating forever what goes where. A single level eliminates the issue.

I think keeping top categories similar to how they currently are and mostly just changing some names can be done. The existing top level organization of the Appearance category is not that bad. Something similar to the status quo has the advantage of already being mostly familiar to existing users.

In T8871#173101, @ngraham wrote:

So for the appearance category, here's my proposal:

Appearance
==========
- Global Theme
- Plasma Style
- Application Style
- Fonts
- Icons
- Colors
- Cursors
- Window Decorations
- Splash Screen

I like this one except idk about Window Decorations - it might make sense to put that under Application Style? (first you do the panel/widgets, then the applications themselves, then their frames, then the fonts, etc.)

In T8871#173104, @rooty wrote:

In T8871#173101, @ngraham wrote:

So for the appearance category, here's my proposal:

Appearance
==========
- Global Theme
- Plasma Style
- Application Style
- Fonts
- Icons
- Colors
- Cursors
- Window Decorations
- Splash Screen

I like this one except idk about Window Decorations - it might make sense to put that under Application Style? (first you do the panel/widgets, then the applications themselves, then their frames, then the fonts, etc.)

Agree.

OK, we could put the window decorations back under Application Style, since that is a thing that (mostly) only affects apps and things that are clearly app windows.

But this reveals a problem with my suggestion: It assumes various KCMs have been merged, which we don't have and won't until everything is ported.

So in reality, this would be the proposal if we were to do it today:

Appearance
==========
- Global Theme
- Plasma Style
- Application Style
-- KDE & Qt Applications
-- GNOME & GTK Applications
-- Window Decorations
- Fonts
-- Fonts
-- Font Management
- Icons
-- Icons
-- Emoticons (or should we delete this because it's useless, as discussed in the VDG room? What was the consensus)
- Colors
- Cursors
- Splash Screen

So in reality, this would be the proposal if we were to do it today:

still a lot tidier imo :D i like it, +1

In T8871#173106, @ngraham wrote:

OK, we could put the windoe decorations back under Application Style, since that is very clearly a thing that (mostly) only affects apps and things that are clearly app windows.

But this reveals a problem with my suggestion: It assumes various KCMs have been merged, which we don't have and won't until everything is ported.

So in reality, this would be the proposal if we were to do it today:

Appearance
==========
- Global Theme
- Plasma Style
- Application Style
-- KDE & Qt Applications
-- GNOME & GTK Applications
-- Window Decorations
- Fonts
-- Fonts
-- Font Management
- Icons
-- Icons
-- Emoticons (or should we delete this because it's useless, as discussed in the VDG room? What was the consensus)
- Colors
- Cursors
- Splash Screen

This can work for me. Some subsections is a good idea.

In T8871#173106, @ngraham wrote:

OK, we could put the window decorations back under Application Style, since that is a thing that (mostly) only affects apps and things that are clearly app windows.

But this reveals a problem with my suggestion: It assumes various KCMs have been merged, which we don't have and won't until everything is ported.

So in reality, this would be the proposal if we were to do it today:

Appearance
==========
- Global Theme
- Plasma Style
- Application Style
-- KDE & Qt Applications
-- GNOME & GTK Applications
-- Window Decorations
- Fonts
-- Fonts
-- Font Management
- Icons
-- Icons
-- Emoticons (or should we delete this because it's useless, as discussed in the VDG room? What was the consensus)
- Colors
- Cursors
- Splash Screen

Still +1

can we? delete the section Emoticons before the merge? is that doable?

In T8871#173110, @rooty wrote:

can we? delete the section Emoticons before the merge? is that doable?

Do we have a good reason to other than it being mostly useless? It technically does still have a use, just not for most people.

Cool. So essentially, all my proposal does is take everything currently under the "Look and Feel" section and put it at the top level. Not so radical after all! :)

no i meant, will we be left with a sidebar saying only Icons
hence Icons Icons :D

i'm in favor of ditching Emoticons I'm just asking if we're able to :D

In T8871#173112, @ngraham wrote:

Cool. So essentially, all my proposal does is take everything currently under the "Look and Feel" section and put it at the top level. Not so radical after all! :)

And some renaming ;-)

In T8871#173112, @ngraham wrote:

Cool. So essentially, all my proposal does is take everything currently under the "Look and Feel" section and put it at the top level. Not so radical after all! :)

ah yes but your proposal is a lot less confusing than master, and a lot more specific :D

Just here for emoticons. We know that removing a feature will lead to a bug report, don't we?
Both Konversation and Choqok are using emotions to display emoji (even thought they are not supported officially anymore in Konvi, but that won't last for long, hopefully).
It is such a small KCM that just makes life easier for the users of those apps, why removing them? I rememberd one of the KDE goals was to implement a global text edit controls that support emoji by default. Even if we don't have that yet, but when we do, we certainly want users to be able to change the icons.
I don't plan to go to Telegram channel to get to know that. I don't need to. KDE uses Phabricator and IRC to be public to everybody and accessible, not private and require softwares and registration.

Not sure where you got the impression that we're going to remove Emoticons. It's still there in the Summary section under the "Things we've agreed on so far" section.

But yes, we definitely want to improve actual Emoji support. However in the meantime the Emoticons KCM is staying around a while longer.

BTW the VDG room is on IRC too (#kde-vdg; see https://community.kde.org/Get_Involved/design), so nobody is forced to use Telegram.

-- Emoticons (or should we delete this because it's useless, as discussed in the VDG room?

Great to have an IRC channel! It was just my two cents, and of course I didn't mean removing the emoticons feature, but the KCM. KEmoticons is still there so why removing that?

Anyway, it's great that we are disccusing again (dunno, for the third time?) the KCMs and System Settings layout. Hopefully this time it's rock solid and goes through.

Hopefully this time it's rock solid and goes through.

That's the idea. We get a lot of complaints about the current organization.

Here's an idea, folks: how about we also move the Desktop Effects KCM out of Desktop Behavior and into the top-level Appearance category? I feel like this might make it more discoverable, and it makes semantic sense since the effects there are almost entirely appearance-based.

In T8871#174037, @ngraham wrote:

Hopefully this time it's rock solid and goes through.

That's the idea. We get a lot of complaints about the current organization.

Here's an idea, folks: how about we also move the Desktop Effects KCM out of Desktop Behavior and into the top-level Appearance category? I feel like this might make it more discoverable, and it makes semantic sense since the effects there are almost entirely appearance-based.

Great idea!

Can the GTK cursor settings be combined with the cursor KCM so that choosing the cursor once works for all applications? New users seem confused about the distinctions between GTK and Qt settings fairly often.

I'd like that very much. In fact I'd like the GTK KCM to disappear or become an appendage to the widget style KCM, because changing things there affect GTK as well as Qt apps.

See:

• https://bugs.kde.org/show_bug.cgi?id=138866 (Fonts)
• https://bugs.kde.org/show_bug.cgi?id=400101 (Color)
• https://bugs.kde.org/show_bug.cgi?id=401507 (Cursors)

Re "Plasma Style", do we want, or can we assume, people to relate "Plasma" to their "Desktop"?

Also, does Splash Screen have to be that prominent? (Can't think of another place to put it, though, so perhaps there's no way around it :/)

In T8871#174059, @broulik wrote:

Re "Plasma Style", do we want, or can we assume, people to relate "Plasma" to their "Desktop"?

We do that whenever we tell people to stop calling it KDE5. I suppose it doesn't *really* matter if users know the DE is called Plasma.

Also, does Splash Screen have to be that prominent? (Can't think of another place to put it, though, so perhaps there's no way around it :/)

It's the last item on the list, so it's not that prominent. There isn't a better place to put it (unless we use Desktop Environment or Workspace as a 1st level category), but I don't think it matters that much.

I think it's good to reinforce our "Plasma" branding. Also "Desktop" is an ambiguous term. To most users, the "Desktop" is the place where they apply a wallpaper and store some of their files.

This task is outgrowing itself lol. I'm going to make it the parent task of one subtask per existing section so we can track the status more easily.

Now I wonder if we should add Security and Privacy as a new top-level category. It would have the Screen Locking, SDDM, and KWallet KCMs in it, and maybe others as we make more security and privacy related stuff in the future.

It also strikes me that the Personalization category needs to disappear and its things moved elsewhere. The concept of "Personalization" implies a user-account-centricity and only makes sense in contrast with things that cannot be changed or are global. Everything in the Appearance section is a type of personalization, for example.

My recommendation is to move some of them to the proposed Behavior section, and others to the currently-empty System Administration section. Good candidates for moving there would be the Users, Font Management, Backups (when Kup is installed), Autostart, and Background Services KCMs.

[spam comment removed by sysadmin]

I was doing some usability testing on the current settings organisation, and here are the results:

• "Plasma" is being interpreted as a material rather than a brand name
• Login screen settings are not in a place people will think to look for them
• Emoticon configuration is associated as being with fonts, not with icons
• Title buttons are associated with window management, not application style
• Date & Time's location resulted in the only "no idea" reply
• Launch feedback is associated with icons or window management rather than applications
• Network shares went completely under the radar - they're under a generic tab labelled "Settings"
• People associate KRunner with the shortcut, not the search

Raw data:

Hi, yesterday I opened a bug because I think that the tab "Tilebar buttons" should be elsewhere. For example in "Window Behavior", since this buttons modify the behavior of the windows. I'm just an user, maybe I'm wrong, but I think that someone could be agree with me. Anyway I also higly doubt we can find a reorganisation that can be good for everyone, so I wonder if "links" could solve this situation. "Links" for me are something similar to the "Frequently Used" in the SystemSettings' main page, but "built in" in the KCM pages. I mean, many tabs can be placed in more than one place because their function overlaps with other, but everyone has his point of view. For example, "Accessibility" module can modify some special behavior of the keyboard, and one could modify its general behavior, too, if we put a link to to KCM_keyboard module (something like "more controls are here..."), and the same in the keyboard module. I think that what we could obtain in this way is a more flexible tool since it could meet many point of view.

I definitely agree that more inter-KCM connections and links would be a good thing. I recently added a crude form of this in D29080.

Yes, I think that more inter-KCM connections should be another keyword here, and you work goes in that direction!
Another example could be that the "Desktop Effects" are tweaked in the "Workspace" section but they should be enabled first in the "Compositor" tab, which is in another section, "Hardware" (btw, what is a compositor? I think someone should add a veeery little explanation of that :) , and it seems that each effect requires also a minimum rendering backend). I think these tab should be linked too.