KCM plugins

Milian Wolff mail at milianw.de
Sun Sep 14 20:58:34 UTC 2014


@Andreas: Thanks for the insight!

@Sven: TOFU! :P

On Sunday 14 September 2014 22:32:53 Sven Brauch wrote:
> I came across this thought as well -- the KCMs are not really a great
> solution here. They require lots of boilerplate code and bring no real
> benefit. A virtual QVector<QWidget*> configPages() in the plugin
> interface-ish solution would be much simpler, no?

I'd personally prefer an explicit API in the UIController over this. Not all 
plugins have config pages, and most will only have on. Doing something like 
the following is much better in that regard (imo):

MyPlugin::MyPlugin(...)
  : IPlugin(...)
  , m_globalConfig(...)
  , m_perProjectConfig(...)
{
    ICore::self()->uiController()->addGlobalConfig(m_globalConfig);
    ICore::self()->uiController()->addProjectConfig(m_perProjectConfig);
}

Now, assuming the config objects are QObjects and get removed from the UI 
controller upon deletion, that's all one needs to do. Much better than having 
to overload some method and returning a list of one object there.

> 2014-09-14 22:31 GMT+02:00 Andreas Pakulat <apaku at gmx.de>:
> > Hi,
> > 
> > On Sun, Sep 14, 2014 at 8:21 PM, Milian Wolff <mail at milianw.de> wrote:
> >> 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.
> > 
> > You're talking about the plugin-specific configuration right? I thought
> > that had been moved into the IPlugin interface meanwhile, but I guess
> > not?
> > 
> > That part is indeed mostly 'code heritage', back then (when moving from
> > kdev3 to kdev4) it seemed like a good idea. KCM's had lots of docs and
> > where quite easy to setup (though it required a hack to get the project
> > config file integrated) and in kdev3 the plugins had access to internals
> > of the project which caused some quite bad interdependencies. And kcm's
> > make it easy to bind kconfig-files to a ui. Only later on it turned out
> > that quite some cases in the plugin configurations do not really benefit
> > from this and not being able to use the binding causes quite some extra
> > code actually. So in retrospec we should probably have thought about a
> > way of adding this to the IPlugin interface or so.
> > 
> > As far as the global settings dialog goes, I guess the reason was that
> > back
> > then we also needed to integrate KTE configs and (IIRC) that was easiest
> > by
> > having a KSettings::Dialog which means having the settings as kcms. If
> > there's a better way to this these days/in kf5 thats great.
> > 
> > Andreas
> > 
> > _______________________________________________
> > KDevelop-devel mailing list
> > KDevelop-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/kdevelop-devel
> 
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel

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


More information about the KDevelop-devel mailing list