[RFC] Extending KCMultiDialog::addModule

[Andreas Pakulat]

On 27.03.07 00:11:08, Matthias Kretz wrote:
> On Monday 26 March 2007 16:07, Andreas Pakulat wrote:
> > On 26.03.07 14:31:16, Matthias Kretz wrote:
> > > On Monday 26 March 2007 13:53, Andreas Pakulat wrote:
> > If the user opens Settings->Configure KDevelop he should only see those
> > items that apply to all of kdevelop.
> 
> 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.

> > If he opens the project 
> > configuration dialog he should see options that relate to that specific
> > project, for example CMake Install Prefix for a cmake based project.
> 
> Don't set a ParentApp for those KCMs but rather use the X-KDE-ParentComponents 
> key. E.g.
> new KSettings::Dialog(QStringList(QLatin1String("kdevelop_cmake_plugin")) << 
> QLatin1String("kdevelop_foobar_plugin"));

Hmm.... 

> > These two dialogs need to be separated (we already tried with only 1 and
> > a combobox and its confusing) and we need a way to initialize the KCM's
> > KConfigSkeleton with the proper configuration file for projects.
> 
> Is it a disjunct set of KCMs for the dialogs or does it overlap? As you can 
> see above both should be easily possible.

Well, for some plugins it might make sense to have a kcm for both. For
those ParentApp would need to be set, right?

> > > > b) it creates kcm's without any arguments
> > >
> > > Are you using the QStringList parameter in KDevelop? I've never seen a
> > > use-case for it so it was hard to incorporate into the API.
> >
> > Well, thats the easiest way to use the existing API on KCModule to
> > provide the configuration file that the KConfigSkeleton should use. Else
> > we'd have to find a way to load the KCM ourselves providing a special
> > constructor we can call and installing this "loading mechanism" into
> > KCModuleProxy or KCMultiDialog. Which is overkill, IMHO, if the
> > arguments API is enough.
> 
> 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.

> solution 2:

Thats what Alexander Dymo came up with two, and thats close to what we
have at the moment (a Config class with static methods, which get the
"current" project). However thats something we don't want, as obviously
this breaks if for some reason the selection on the list of projects is
cleared (for example when opening the first project). Also when
introducing the notion of a "current" project, things get much more
complicated when handling multiple projects.

> > So for example 
> > if you open the configuration for projectA which uses CMake you don't
> > want to see the kcm for QMake or Autotools. Or if that project doesn't
> > use any C++ files, only Python files you don't want to see the options
> > specific to C++ either. So all that KSettings::Dialog adds to
> > KCMultiDialog from that perspective is the creation of the tree by using
> > the CfgDlgHiearchy info (unless I overlooked something).
> 
> And the KService lookup. If you use KCMultiDialog::addModule you need to 
> gather the information about all the KCMs you need to load. With 
> KSettings::Dialog you only have to gather the component names, i.e. the 
> plugins the project uses and it will figure out the KCMs from that. It's easy 
> to extend the dialog afterwards with plugins, without the need to change 
> anything in the app.

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.

> > 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?

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).

andreas

-- 
You are only young once, but you can stay immature indefinitely.