Hierarchical KCM page invocation schema instead of dedicated binary?

Currently, systemsettings5 exposes its KCMs via kcmshell5, listable with kcmshell5 --list and invocable with kcmshell5 $KCM. I expect that this approach is useful because the non-hierarchical organization means that re-organization is easy because the current organization isn’t programmatically depended upon.

However, this has a few issues, and I do not believe should mean that this method should mutually exclude hierarchical organization, because

  • The KCM listing is non-hierarchical, so investigating what configuration page correlates to which KCM’s ID is not necessary intuitive.

  • Noticing extensions to the functionality/organization of a KCM isn’t necessarily obvious for a developer, because there is no hierarchical correlation between KCMs when exposed in this manner. Say, for instance, I want to invoke a sub-window of a KCM not exposed as a KCM in its own right, there is no standard way for me to provide this ability except by separating it into its own KCM.

    For instance, from Chat does not adhere to system text size preference, but should. · Issue #10016 · ValveSoftware/steam-for-linux · GitHub

    1. image

    I certainly don’t know of an obvious way to invoke that window.

Additionally, more broadly, in situations such as these, where applications want to expose to a developer/user the ability to invoke specific pages, they use non-discoverable binaries like lookandfeeltool.

Wouldn’t something like kde://settings/display_configuration be much more discoverable? Having something like kde:// as the root makes virtual sub-directories discoverable, and exposing high-level directories like settings as their own schemas (settings://) in order to make it resilient to an application deciding to separate from KDE would make this surprisingly versatile.


  • kde://settings/display_configuration replacing kcmshell5 kcm_kscreen
  • kde://settings/ replacing kcmshell5 --list
  • kde://settings/appearance?set=org.kde.breezedark replacing lookandfeeltool --apply org.kde.breezedark.desktop

(Or augmenting, instead of replacing, of course.)

Steam, for instance, has somewhat recently switched to this method, per Steam browser protocol - Valve Developer Community.

Has this option been considered, and do you know of, or can envision, any potential downsides?


I don’t really see how this would improve anything visibly to warrant all of the work. Settings should be set in the KCMs (that’s why we put so much effort into them!) and launching via CLI isn’t exactly a common usecase for users.