[RFC] Extending KCMultiDialog::addModule

[Andreas Pakulat]

On 27.03.07 16:16:05, Matthias Kretz wrote:
> On Tuesday 27 March 2007 00:46, Andreas Pakulat wrote:
> > On 27.03.07 00:11:08, Matthias Kretz wrote:
> > > Is "all of kdevelop" a fixed set of configuration options or does it
> > > depend on installed plugins? If the former, then you obviously don't need
> > > KCMs at all. So I guess the latter. Then install all those KCMs with
> > > ParentApp=kdevelop and create a simple KSettings::Dialog().
> >
> > Right.
> 
> BTW, if you have optional plugins that show KCMs in the main config dialog you 
> should be interested in Dialog(Configureable, ...). :-)

I already noticed that part :) But we're not sure yet how to tackle user
preferences wrt. using/not-using plugins (the multi-project-approach
adds a whole new side to this).

> > > solution 1:
> > > add a method to KSettings::Dialog to set the QStringList args which will
> > > then be used in the KCMultiDialog::addModule calls.
> >
> > Hmm, I thought that wouldn't fit the KSettings::Dialog that well, otoh
> > if KCMultiDialog allows to add arguments to the kcm's then this dialog
> > should do so too.
> 
> The reason KSettings::Dialog didn't provide a way to specify args is really 
> that simple: I didn't know a use-case and therefore didn't know how the API 
> should look like. So I omitted it.

Well, I added it now to the constructor, basically because
KSettings::Dialog doesn't have an API to clear the dialog and reload
modules using a different list of components and I think we will have N
dialogs for N different projects (if the user is so crazy to open them
all).

> > Well, given how you described the possibility using the ParentComponent
> > to list the plugin it relates to, this should be rather easy. Fetching
> > the plugins we want to show configuration for is needed anyway. This
> > sounds really good.
> 
> Take a look at kdelibs/kio/kcmodule.desktop (btw, there's no good reason for 
> this to be in the kio dir anymore. Probably all service descriptions should 
> be moved into kdelibs/services or so). The last three keys (ParentComponents, 
> CfgDlgHierarchy and Weight) are used by KSettings::Dialog to query the trader 
> and put the modules in a tree (sorted by weight). Of course an app can reuse 
> those keys to implement the same logic, but IMHO that's what KSettings is 
> good for...

Yeah, I won't implement the same logic, all I will do is find the proper
list of ParentComponents that I need to pass to KSettings::Dialog. I
didn't see this possibility, thats why I first wanted to do everything
on my own using KCMultiDialog...

> > > > I'm not yet sure how we describe which kcm's need to be loaded, I guess
> > > > a plugin would list the names of all kcm's that it needs.
> > >
> > > That's opposite to the idea of how KSettings::Dialog works. I wanted the
> > > plugin to not know about the KCMs at all (well except that it needs to be
> > > told when it's config file has changed).
> >
> > Hmm, do you have a link to a doc that explains how this is done? I
> > didn't see anything in the KSettings apidox?
> 
> http://api.kde.org/cvs-api/kdelibs-apidocs/kutils/html/namespaceKSettings.html

Aaah, so to have my plugins notified I need to use the name they
KComponentData contains and register them with the
KSettings::Dispatcher.

> > Thanks for information, so I will proceed and add a setModuleArguments
> > method to KSettings::Dialog. If I'm not mistaken these changes are ok to
> > commit on a non-monday right (as people don't need to update kdelibs to
> > have their apps compile again).
> 
> It's ok to add methods to kdelibs on non-mondays, yes. It's not ok to depend 
> on those methods in other modules than kdelibs, though, as that forces an 
> update of kdelibs on everybody that wants to compile this module. (You could 
> simply disable the relevant code in kdevelop until next monday)

Hehe, well, if it weren't for the various automatic compilation sites I
could do this too, because I can notify all kdevelop developers of this
change ;) Anyway, I won't have time before the weekend to do all the
necessary changes in KDevelop, so thats not a problem.

I'll add my stuff later today (need to get the various build problems
sorted out before), thanks again for the explanations and hints. 

Andreas

-- 
Stay the curse.