KCM plugins

[Christoph Cullmann]

> 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)
Hi,

if you do it that way around, will the plugin create the config pages
then on loading? IMHO the biggest benefit of the way we do it at the moment
is, that the config pages will only be created on demand, if the dialog is shown.

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234