This doesn't build for me:

/home/nate/kde/src/systemsettings/app/main.cpp: In function ‘int main(int, char**)’:
/home/nate/kde/src/systemsettings/app/main.cpp:115:91: error: ‘endl’ was not declared in this scope; did you mean ‘std::endl’?
  115 |         std::cout << i18n("The following modules are available:").toLocal8Bit().data() << endl;

In D29064#654956, @ngraham wrote:

Foor fod thought: we might want to also think about some of the consequences of removing kcmshell; we could need to add programmatic cross-KCM navigation into system settings itself. For example, in D29080, I'm calling kcmshell from inside a KCM to pop-up the KScreen KCM on top of the fonts KCM.

i guess it doesn't have to be removed completely (kcmshell itself is so little code that isn't really a big maintainance overhead) one thing that could be done probably is just changing krunner to launch systemsettings instead and leaving the rest unchanged.

the *really* annoying thing is that every single kcm has a line like

Exec=kcmshell5 kcm_lookandfeel

in its desktop file. Which would call something along the lines of what we did for kinfocenter, to still have kcmshell5 as a symlink, but in this case i don't think it would cover all cases?

Without kcmshell, that won't work as currently implemented, and it would need to navigate you to the KScreen KCM in the same systemsettings instance.

Also a new way to get the information from kcmshell5 --list would be nice.

systemsettings5 --list works ;)

In D29064#655349, @mart wrote:

the *really* annoying thing is that every single kcm has a line like

Exec=kcmshell5 kcm_lookandfeel

in its desktop file. Which would call something along the lines of what we did for kinfocenter, to still have kcmshell5 as a symlink, but in this case i don't think it would cover all cases?

Without kcmshell, that won't work as currently implemented, and it would need to navigate you to the KScreen KCM in the same systemsettings instance.

Yeah I guess a compatibility symlink that opens systemsettings5 will be necessary.

Also a new way to get the information from kcmshell5 --list would be nice.

systemsettings5 --list works ;)

Excellent!

Note you can pass multiple arguments to kcmshell5 to open a dedicated save window with random KCMs inside, e.g. done by battery monitor:

kcmshell5 powerdevilprofilesconfig powerdevilactivitiesconfig powerdevilglobalconfig

Not sure how this could be translated 1-on-1 :/
Though power management is its own group, so maybe we could port that over to passing the parent category in or something. But reimplementing that in systemsettings looks like a rabbit hole we don't want to do down into.