[RFC] Extending KCMultiDialog::addModule

[Matthias Kretz]

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

It currently is not implemented the way I'd like to use it and probably needs 
a usability person to take a look at it, but here are the main points how I 
believe it should work:
- The dialog always shows all possible configuration pages, if the plugin is 
disabled, the KCM is disabled. That way the structure never changes except if 
KCMs are (un-)installed.
- Plugins can be enabled/disabled using a checkbox in the list of available 
config pages. That way the page selection widget becomes the component 
selector at the same time.
- When a component is selected/deselected the config pages become 
available/unavailable immediately; no need to press apply.

See http://vir.homelinux.org/ksettings-mockup.png

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

Exactly.

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

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

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

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

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

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070327/dad9c684/attachment.sig>