[RFC] Extending KCMultiDialog::addModule

[Andreas Pakulat]

On 26.03.07 14:31:16, Matthias Kretz wrote:
> On Monday 26 March 2007 13:53, Andreas Pakulat wrote:
> > trying to work out KDevelop4's configuration stuff I hit a problem.
> > Currently it uses KCModule's to provide configuration widgets and
> > kconfigxt stuff, however we need to separate application-global
> > configuration from project-specific configuration.
> 
> Does that mean you need two different dialogs? What do you mean 
> with "separate"?

Separate means we work on different configurations. For app-global stuff
(like maybe enabling/disabling menubar, dunno nothing that qualifies
for this exists atm) we store this in kdeveloprc in share/config/,
however we also want to use the ini-format for the kdevelop project
files and thus use the existing stuff that handles such configuration
files, i.e. KConfigXT and KCM (for the widgets). 

> > There are two problems when I look at KSettings::Dialog
> >
> > a) it always loads all kcm's that have ParentApp=kdevelop set.
> 
> Well, if you open the KDevelop settings dialog don't you want to see all 
> configuration pages that belong to kdevelop? I don't understand the problem, 
> but that probably can be fixed by explaining the above question. :-)

If the user opens Settings->Configure KDevelop he should only see those
items that apply to all of kdevelop. 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.
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.

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

> > Now a) could be worked around by setting ParentApp to some non-existant
> > appname (like kdevelop-project) and use ParentComponents with the same
> > thing. However b) can only be changed by changing API in kutils.
> >
> > Now as the solution for a) is also rather hackish I think kdevelop will
> > use its own methods of discovering the "right" kcm's and createh
> > KCModuleInfo from that. This means we don't need KSettings::Dialog but
> > can use KCMultiDialog.
> 
> You can, but the idea of KSettings::Dialog is to help applications (that 
> depend a lot on plugins) solve the settings dialog problem. If it doesn't 
> work it needs to be fixed. There are few enough applications that need it so 
> that I believe it's right to exist ceases when applications cannot use it 
> because it's too limited.

Well, we want to customize the list of shown kcm's on a per project base
as we allow to open multiple projects at the same time. 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). 

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. So we'd need
to tell KSettings::Dialog which plugins to load and the arguments that
all kcm's should be given. This clearly interfere's with the idea behind
KSettings::Dialog, which is to display all kcm's for a particular app,
regardless of wether its from the app itself or a plugin that was
written for the app or for some other app but also applies to this
application.

Andreas

-- 
You are a fluke of the universe; you have no right to be here.