KCM plugins

Dominik Haumann dhaumann at kde.org
Tue Sep 16 08:50:08 UTC 2014


On Monday 15 September 2014 22:39:22 Milian Wolff wrote:
> 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

Agreed, would be an option to change the API. The good news is that this is a 
simple for loop that will be easy to maintain, so for now not a big deal ;)

> Or is this also to delay stuff? 

In fact, yes: We once loaded a created a config page only once the user 
clicked on the entry. It has the advantage that you also do not have to save 
anything in case the config widget was not created.

However, we switched over to always load all config pages (once the config 
dialog is shown) in KDE 4.x times, because otherwise we don't know in advance 
the config widget's size, which then results in window resizes, which is 
totally ugly.

Greetings,
Dominik


> We'll need to extend the API though to also offer plugins the
> ability to add per-project config pages.
> 
> Bye



More information about the KDevelop-devel mailing list