KCM plugins

[Milian Wolff]

Hey Alex,

are you registered to kdevelop-devel at kde.org? If not, please do so.

First up, many thanks to your recent contribution in regard to plugin loading 
via embedded JSON data vs. .desktop files. Last week, at this years Akademy 
conference, I chatted with David Faure about this topic a bit. I always 
wondered why we have our KCMs in plugins and he confirmed that is not required 
in our usecase. Probably this is some old code heritage.

So, if you want to continue to work in that regard on KDevelop, I'd greatly 
appreciate if you could take a look at getting rid of the plugin separation 
for KCM's. This should greatly cleanup our code base. What I have in mind is 
something along the following lines:

a) We have two places where we show KCMs currently:
  1) In the global kdevelop settings dialog:
	UiController::showSettingsDialog
  2) In the pre-project config dialog:
	ProjectContoller::projectConfig
b) both currently use the plugin magic to show KCMs in a KSettings::Dialog. 
This will need to be refactored. Instead, we should aim for something similar 
to what KTextEditor is doing already, see e.g. src/dialoags/katedialogs.h and 
the inheritors of KateConfigPage/KTextEditor::ConfigPage. In general, we 
should try to mimick what Kate is doing currently. See 
kate/kate/src/kateconfigdialog & friends. This will allow us to have one 
unified "configure kdevelop" dialog that also shows the KTextEditor 
configuration pages.
c) The existing KCM's will need to be thrown away, instead we probably want to 
extend the UIController to allow plugins to register per-project as well as 
global configuration pages.

This is quite some work. But I wanted to mention this as you where working on 
something in that regard. And note: If Alex doesn't want to do that, anyone 
else is invited to refactor our code in that regard!

Cheers, comments welcome!
-- 
Milian Wolff
mail at milianw.de
http://milianw.de