Systematic KCM reorganisation
Open, NormalPublic

Description

After now several individual KCMs have been ported from Qt Widgets to Kirigami/QML code, we should discuss again the overall organisation of KCMs.

Current KCM mechanism reorganisation
This means foremost:

  • which KCMs provides which settings,
  • how the KCMs are sorted/categorized,
  • and how the KCMs are interconnected if at all.

Currently many KCMs are defined by the technical implementation and not from a user viewpoint. For example KWin provides several KCMs, which are only about KWin, but often affect the overall "Workspace experience" and might be better combined with other KCMs provided by Plasma, but can't because of our need for modularity.

A good analysis of this problem was written up by @broulik not long ago:

A problem is also our modular nature, we always think in components, there's a KWin decoration KCM, there's a BlueDevil module, there's a NetworkManager module, etc. We don't have a "connectivity" module and a "window management" module, it's all split and separate and even settings that would make sense together are split because they're with their respective components rather than where it semantically makes sense.
That's partially due to the fact that we want other people to use our stuff, e.g. lxqt using KWin and so on, so having a standalone setting for KWin stuff makes sense for that but that obviously jeopardizes a wholly integrated solution compared to e.g. Android's settings.

Another problem is that KCMs are top-level organised only and their categorization as in System Settings is a completely independent mechanism. KCMs were not designed with a cascading structure in mind, one KCM housing other ones. This limits us severely in combining KCMs and led to too many top-level KCMs overall in the past.
Way forward
I propose to not directly throw away everything and redo it, but we should at least think about how the optimal System Settings would be organised in our opinion. For that we can look back at our own current organisation, how other DEs are doing it and how we would do it from a pure logical perspective. We can then try to approach this optimum with our current KCM mechanism and see how far we come. Afterwards we will be able to decide if the current KCM mechanism needs to be enhanced or replaced.

Things we've agreed on so far

Appearance section

- Global Theme

- Plasma Style

- Application Style
-- KDE & Qt Applications
-- GNOME & GTK Applications (Would like this merged into the above KCM, at this point it would be renamed appropriately)
-- Window Decorations

- Fonts
-- Fonts
-- Font Management

- Icons
-- Icons
-- Emoticons (Would like this merged into Icons or eliminated after full Emoji support is mature)

- Colors

- Cursors

- Graphical Effects

- Splash Screen
There are a very large number of changes, so older changes are hidden. Show Older Changes
romangg updated the task description. (Show Details)May 25 2018, 10:40 PM
romangg added a subscriber: broulik.

One thing that should be addressed is the duplication between the 'Audio Volume' (plasma-pa) and the 'Audio and Video' (Phonon?) KCM.

ngraham added a subscriber: ngraham.EditedMay 26 2018, 2:29 AM

An excellent topic of discussion. In terms of top-level organization, think System Settings is actually not that bad already. The top-level sections that we already have for the most part do a good job of grouping the sections into user-focused tasks ("change the appearance", "change how I interact with the hardware", etc). The grouping we've chosen is a fairly common one--in fact it's very similar to macOS System Settings' sections.

That said, there's a lot of roughness around the edges and instances of technical terminology and implementationd details leaking up to the surface. Here are a few things that come to mind:

Appearance

  • Look & Feel has an unclear relationship to the other appearance items. It is something separate? Does it affect all of them? What happens if you change your L&F but then tweak something else?
  • It's not clear what affects apps and what affects Plasma. The use of the word "Workspace" instead of "Plasma" doesn't help things. Sometimes the color theme affects Plasma, but sometimes it doesn't?
  • What is the Emoticons KCM actually used for?

Workspace

  • What's a workspace? Isn't this whole computer my workspace? What does this section mean? Perhaps the word "Behavior" would be better.
  • Desktop effects: doesn't this stuff basically control the appearance? Why isn't it up there?
  • Screen Locking should probably be visible in the sidebar as one of the top-level categories.
  • The whole Shortcuts section needs a lot of work, as I think most folks are well aware.

Personalization

  • Most of the KCMs under Applications are really specialized and dated. I bet a lot of this stuff could be consolidated in a more hidden place; how often do people really need to configure their system locations or see an enormous list of file types and their associated apps?
  • Online accounts needs way more account types to be useful.

Network

  • Most of the KCMs in this section are entirely too technical or downright inapplicable--especially nearly everything under the Settings category if you're not using Konqueror (which is unmaintained and deprecated anyway)
  • The Connectivity KCM is literally useless.

Hardware

  • Do we really need to show input device KCMs for hardware that's not detected? Joystick, Mouse, Touchpad, Optical disk settings, etc.
  • The KWin Touch Screen KCM should be moved here.
  • We really need to merge the Audio Volume and Audio and Video KCMs, not only from a UX perspective, but also because it will allow us to fix a much-requested bug: https://bugs.kde.org/show_bug.cgi?id=392117
  • Power Management could really use a UX overhaul, and maybe a less technical name. Perhaps "Energy Saving".

I would also submit to have a section for either OTHER, or GENERAL, or MOST FREQUENTLY USED.

The idea would be to have a place where KCMs can go when they simply don't fit anywhere else. I would not call it OTHER but I would have a place to put them.

The home page view already shows "Most frequently used", though it's only visible when you first open the app, and there's no way to go back there later.

IMHO most of the general/random/catch-all things should go under the proposed top-level Behavior section.

ngraham added a comment.EditedJun 11 2018, 4:40 AM

One thing I'd really like to do away with is the current inconsistent two-level organizational hierarchy, where some items at the top level take you straight to a KCM, while others take you to another level of navigation where several KCMs are displayed in a little list. In these cases, I think it would be great if we could merge content where possible, and when we can't do that, we should consider a regular old tabbed view. This will of course require some design work so we don't run into situations where we have a tabbed view immediately inside another tabbed view! In some cases (e.g. SDDM KCM) the content in an "Advanced" tab could easily be hidden behind an Advanced button instead. In others (e.g. Widget Style KCM) there's room on the main view for both tabs to be merged.

Here's a first crack as a "user-centric" layout:

Appearance

  • Global Theme
  • Colors
  • Fonts (merge into a tabbed view)
  • Icons (merge into a tabbed view)
  • Application Style (merge all into a single KCM if possible)
  • Desktop Effects

Behavior

  • General (New name for the "Workspace Behavior" KCM; merge contents of Desktop Session KCM)
  • Applications (merge all into a single KCM if possible)
  • Security & Privacy (Contains Screen Locking, SDDM, and KWallet KCMs in a tabbed view)
  • Window Behavior (Somehow merge or contain all content in these KCMs; seems like a challenge)
  • Virtual Desktops & Activities (merge and put each one's content into one tab of a tabbed view; ideally in the future we collapse the distinction between these...)
  • Screen Edges
  • Search (merge into a tabbed view)

Personalization

  • User accounts (merge contents of autostart KCM, making it clear that these are per-user settings)
  • Language & Formats (Contains Language, and Formats KCMs in a tabbed view)
  • Date & Time
  • Notifications (merge all into a single KCM if possible)
  • Accessibility
  • Online Accounts

Hardware & Devices

  • Keyboard (includes Spell Check and Shortcuts KCMs)
  • Mouse, Touchpad, Joystick, Drawing Tablet/Touch screen (only show the ones that actually correspond to a currently-connected device)
  • Display & Monitor (merge into a tabbed view)
  • Audio & Video (merge all into a single KCM if possible)
  • Printers
  • Energy Saving (merge all into a single KCM if possible)
  • Removable Storage (merge into a tabbed view)
  • KDE Connect (only show after the first time a compatible device is connected)

Network

  • Connections (merge with Proxy KCM and hide all the other KCMs under Settings under an Advanced button
  • Bluetooth (merge all into a single KCM)

Pretty interesting and I agree. There should not be a whole lot of navigation. My .2 cents are that we make also our search very prominent. I can make mockups based on your suggestions Nate.

abetts updated the task description. (Show Details)Jun 13 2018, 4:49 AM
zzag added a subscriber: zzag.Jun 13 2018, 3:29 PM

There was a very large effort to reorganize the KCMs in the past:
https://community.kde.org/KDE_Visual_Design_Group/System_Settings_Application

ngraham added a comment.EditedJun 14 2018, 1:39 PM

Yeah, and I think the goal here is to build on that effort, further improving things by:

  • Reducing navigational complexity
  • Renaming KCMs to reflect user intentions instead of exposing technical origin or grouping
  • Re-organizing KCMs to appear in more user-focused locations
This comment was removed by abetts.
abetts updated the task description. (Show Details)Jun 14 2018, 2:39 PM

Any more thoughts on my proposed re-organization above?

One thing I'd really like to do away with is the current inconsistent two-level organizational hierarchy, where some items at the top level take you straight to a KCM, while others take you to another level of navigation where several KCMs are displayed in a little list.

+1

==Behavior==

  • Security & Privacy (Contains Screen Locking, SDDM, and KWallet KCMs in a tabbed view)

I am not sure if I would expect the screen lock in security & privacy... The Screen Lock KCM also includes some appearance elements, maybe separate those?

  • Window Behavior (Somehow merge or contain all content in these KCMs; seems like a challenge)

Yeah, that seems like a hard task and I think it'd be bad if we had too many tabs in a single KCM to properly organize all settings. But then again, I cannot really think of a better solution...

==Personalization==

  • User accounts (merge contents of autostart KCM, making it clear that these are per-user settings)
  • Language & Formats (Contains Language, and Formats KCMs in a tabbed view)
  • Date & Time
  • Notifications (merge all into a single KCM if possible)
  • Accessibility
  • Online Accounts

+1

==Hardware & Devices==

  • Keyboard (includes Spell Check and Shortcuts KCMs)
  • Mouse, Touchpad, Joystick, Drawing Tablet/Touchscreen (only show the ones that actually correspond to a currently-connected device)

Any reason why we cannot let those merged into "Input devices" like it is now? Also, I am not convinced that users would expect shortcuts in the keyboard settings, the Behavior group seems more fitting to me.

==Network==

  • Connections (merge with Proxy KCM and hide all the other KCMs under Settings under an Advanced button
  • Bluetooth (merge all into a single KCM)

Maybe consider putting those into Hardware & Devices as well?

I think this is a good step forward from what we have: we do not alienate current users because the changes are rather small but still improve the overall experience.

ngraham added a comment.EditedJun 19 2018, 1:19 PM

==Behavior==

  • Security & Privacy (Contains Screen Locking, SDDM, and KWallet KCMs in a tabbed view)

I am not sure if I would expect the screen lock in security & privacy... The Screen Lock KCM also includes some appearance elements, maybe separate those?

In an earlier revision, I considered having Screen Locking visible at the top level, which would certainly make it more discoverable. But then I couldn't think of a good place to put the SDDM and KWallet KCMs without making the Behavior top-level category way too huge, so I came up with the idea of a Security & Privacy KCM to hold them all. But maybe that would be okay? Open to suggestions for improvement.

==Hardware & Devices==

  • Keyboard (includes Spell Check and Shortcuts KCMs)
  • Mouse, Touchpad, Joystick, Drawing Tablet/Touchscreen (only show the ones that actually correspond to a currently-connected device)

Any reason why we cannot let those be merged into "Input devices" like it is now?

I feel like the individual device KCMs should be visible at the top level. "Input Devices"--as obvious as it might seem to us--is a fairly technical term. For regular users, it may not be obvious that a mouse or a touchpad is an "input device." GNOME and macOS both have the individual device pages visible at the top level, for comparison.

Also, I am not convinced that users would expect shortcuts in the keyboard settings, the Behavior group seems more fitting to me.

I'm not strongly wedded to this proposal, but I felt like it made sense since the only shortcuts you can actually set there are keyboards shortcuts. Again for comparison, GNOME and macOS also both have their customizable shortcut UIs on their the Keyboard pages.

==Network==

  • Connections (merge with Proxy KCM and hide all the other KCMs under Settings under an Advanced button
  • Bluetooth (merge all into a single KCM)

Maybe consider putting those into Hardware & Devices as well?

I considered that, but then Hardware & Devices would have ten items, which seemed like a bit much. Suggestions?

Maybe we could combine the content from the kscreenlocker and SDDM KCMs into a new "Lock & Login screen" KCM? Then the KWallet KCM could be a top-level KCM under Personalization or be combined with something else.

Maybe we could combine the content from the kscreenlocker and SDDM KCMs into a new "Lock & Login screen" KCM? Then the KWallet KCM could be a top-level KCM under Personalization or be combined with something else.

That sounds good and more intuitive to me, but please do not consider my opinion to be more than just random thoughts (I am by no means a UI/UX expert) so I think we should hear a few additional opinions from the VDG first.

I'm not strongly wedded to this proposal, but I felt like it made sense since the only shortcuts you can actually set there are keyboards shortcuts. Again for comparison, GNOME and macOS also both have their customizable shortcut UIs on their the Keyboard pages.

Aren't e.g. mouse gestures also included in this KCM?

I considered that, but then Hardware & Devices would have ten items, which seemed like a bit much. Suggestions?

Yeah, that's obviously not ideal. If we do want to keep the individual devices exposed at the top level then you are right to create an additional category.

Another question: There are currently three tabs in the Network (Cookies, Local Storage & and the Browser Fingerprint one) which are as far as I know only important for Konqueror. Is that correct? If yes, can we somehow hide those if Konqueror is not installed?

What is next to be done here? I feel the team seems to agree. Should we present this at Akademy?

For the appearance:
maybe it could be made more obvious that Global Theme is a superordinate to the others?

At least as far as I understood it, with a global theme you change (potentially) all the other points at once:

  • Colors
  • Fonts (merge into a tabbed view)
  • Icons (merge into a tabbed view)
  • Application Style (merge all into a single KCM if possible)
  • Desktop Effects ?

For the appearance:
maybe it could be made more obvious that Global Theme is a superordinate to the others?

At least as far as I understood it, with a global theme you change (potentially) all the other points at once:

  • Colors
  • Fonts (merge into a tabbed view)
  • Icons (merge into a tabbed view)
  • Application Style (merge all into a single KCM if possible)
  • Desktop Effects ?

I agree, and had considered this myself. I didn't manage to come up with anything yet though.

P.S. nice use of the word "superordinate"! :)

For the appearance:
maybe it could be made more obvious that Global Theme is a superordinate to the others?

At least as far as I understood it, with a global theme you change (potentially) all the other points at once:

  • Colors
  • Fonts (merge into a tabbed view)
  • Icons (merge into a tabbed view)
  • Application Style (merge all into a single KCM if possible)
  • Desktop Effects ?

I agree, and had considered this myself. I didn't manage to come up with anything yet though.

P.S. nice use of the word "superordinate"! :)

Maybe the UI here could also come a long a little better. Right now for Global Themes we have a screenshot style that may need improvement. I wonder if there is a graphical way that we can describe to the user that this global theme has Icons Theme X, Toolbar Theme X, etc. Just a little more descriptive.

Plasma 5.15 Kickoff meet comments:
<notmart> "Re-organize System Settings hyerarchy" is the one thing i wanted to keep "forbidden until rewrite is done"
<d_ed> it's a top-down moving things around, rather than the bottom-up doing the work cleaning things

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.

GB_2 added subscribers: ndavis, GB_2.

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
ndavis added a comment.EditedJan 13 2019, 11:29 AM

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

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:

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.


I think it'd be ok, considering it would show some of the best configuration options Plasma provides.

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!).

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?

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.

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.

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.

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 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).

GB_2 added a comment.Jan 13 2019, 5:37 PM
This comment was removed by GB_2.

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
GB_2 added a comment.Jan 13 2019, 7:04 PM

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

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.

rooty added a comment.EditedJan 13 2019, 7:06 PM

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.)

GB_2 added a comment.Jan 13 2019, 7:07 PM
In T8871#173104, @rooty 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.

ngraham added a comment.EditedJan 13 2019, 7:09 PM

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
rooty added a comment.Jan 13 2019, 7:10 PM

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

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.

GB_2 added a comment.Jan 13 2019, 7:11 PM

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

rooty added a comment.EditedJan 13 2019, 7:11 PM

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! :)

rooty added a comment.Jan 13 2019, 7:13 PM

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

GB_2 added a comment.Jan 13 2019, 7:13 PM

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 ;-)

rooty added a comment.EditedJan 13 2019, 7:14 PM

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

ngraham updated the task description. (Show Details)Jan 13 2019, 7:24 PM

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.

GB_2 added a comment.Jan 20 2019, 6:49 PM

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!

ngraham updated the task description. (Show Details)Jan 20 2019, 7:28 PM

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:

broulik added a comment.EditedJan 21 2019, 8:51 AM

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 :/)

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.

ngraham updated the task description. (Show Details)Jan 25 2019, 10:04 PM
GB_2 updated the task description. (Show Details)Jan 25 2019, 10:05 PM
GB_2 added a comment.Apr 8 2019, 6:09 PM
This comment was removed by GB_2.