Design Recommendations

The content of an KCM may not be, from the user's point of view, application specific. KControl's purpose is to in a central place provide configuration for functionality which is global for KDE. Keeping application specific configuration in KControl simply makes it too big and bloated(people have already tried this). Technically, the functionality the KCM represents can be an application or isolated and separated but that is irrelevant - it is about how the users percepts and sees it, not how it is implemented.

We don't want configuration. In a perfect world the default settings fits everyone and the hardware Just Works. This is not the case so we have KControl.
But that is no reason to have unnecessary options and bloat in a KCM. For every configuration option you could ask:

• Is this option really, really necessary?
• Does a significant part of KDE's users need it?
• Does other KCMs have similar options which could be combined into a global one?
• Could the implementation be changed so the user does not have to take the (configuration) decision?
• Does the configuration item exist as a work around for a bug?
• Is the configuration item only useful for the developers?

Overall, The goal is to provide a configuration interface that is as compact as possible while maintaining clarity and allowing the user to easily configure relevant aspects of the system.

Any given setting should appear exactly once in one and only one KCM. Also, ensure the KCM is not available in several places in KControl, for example once as stand alone KCM and in another case on a tab in another KCM. Including KControl's KCMs in other applications for convenience is on the contrary a good idea. If you feel a need of making the KCM available in several places, it is an alarm bell for something is wrong:

• Perhaps you need to split up the functionality in different KCMs?
• Is the Name wrong?
• Perhaps even the top level categories are wrong? In either case, discussing it on kde-usability is a good idea.

If a KCM contains clearly separated functionality but it is still most convenient if they are in one KCM, it can many times be a good idea splitting the functionality into several different KCMs and then encapsulate those in one KCM. This allows very flexible code arranging as well as applications which need KControl KCMs can be more specific in what functionality they want. The code is simple, a study case is the "Hardware/Display" KCM which encapsulates the "gamma" and "randr" among other.

Design around how a user interacts with what they are configuring rather than around implementation details found in the source code. A design should follow the steps most people would take to accomplish a task rather than expose how the application actually works.