KCM plugins

[Alexander Richardson]

Hi,

2014-09-14 20:21 GMT+02:00 Milian Wolff <mail at milianw.de>:
> Hey Alex,
>
> are you registered to kdevelop-devel at kde.org? If not, please do so.

Yes, I am registered.

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

I had a look at how kate handles the config pages and a similar
approach for KDevelop
seems like a good idea to me. I will continue to work on the plugin
loading code and
try to completely get rid of the need for kbuildsycoca.

I also think that having the plugin register the config pages instead
of adding another
two virtual methods to IPlugin seems the better approach.

I.e. UiController::addGlobalConfig(KTextEditor::ConfigPage* page)
and UiController::addProjectConfig(KTextEditor::ConfigPage* page)

Or do we want to allow Plugins to define a whole Tree of config pages?
We could add a class KDevelop::ConfigPage which extends KTextEditor::ConfigPage
and adds a method QVector<KDevelop::ConfigPage*> childPages().

However, it might also be desirable to add a child item to a config
page that is not created
by the current plugin, should we handle this?

I guess we have to make sure that these QWidgets have a correct parent set since
otherwise unloading will crash?

Regards,
Alex