KCM plugins

[Milian Wolff]

On Monday 15 September 2014 22:16:21 Christoph Cullmann wrote:
> > 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.

Hm, good point. Also considering that we'll want to integrate more with Kate's 
API in general, it might be a good idea to reuse their API. Even though I have 
to say that your choice of this:

    virtual int configPages() const;
    virtual ConfigPage *configPage(int number, QWidget *parent);

instead of returning a list is pretty ugly :P Or is this also to delay stuff? 
We'll need to extend the API though to also offer plugins the ability to add 
per-project config pages.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de