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