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.
**Current KCM mechanism itself under question**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
```
In this context a fundamental and somewhat unpleasant question is also if the current KCM mechanism overall needs an overhaul.- Global Theme
- Plasma Style
One issue is, that KCMs are defined by the technical solution 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.- Application Style
-- KDE & Qt Applications
-- GNOME & GTK Applications
-- Window Decorations
A good analysis of this problem was written up by @broulik not long ago:- Fonts
> 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.-- Fonts
> 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.-- Font Management
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.- Icons
-- Icons
**Way forward**-- Emoticons
- Colors
- Cursors
- Splash Screen
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.```