[RFC] Extending KCMultiDialog::addModule

[Matthias Kretz]

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

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

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

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

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

solution 2:
add a Singleton or global variable that you can set from the app and read from 
the KCMs which will give you the KSharedConfig::Ptr
example:
projectconfig.h:
namespace KDevelop
{
  KSharedConfig::Ptr projectConfig();
  void setProjectConfigFile(const QString &);
}

projectconfig.cpp:
namespace KDevelop
{
struct ProjectConfigData
{
  KSharedConfig::Ptr config;
};
K_GLOBAL_STATIC(ProjectConfigData, projectConfigData)
KSharedConfig::Ptr projectConfig()
{
  return projectConfigData->config;
}
void setProjectConfigFile(const QString &filename)
{
  projectConfigData->config = KSharedConfig::openConfig(filename);
}
} //namespace

now put the above in a lib that the KCMs link to and call 
KDevelop::setProjectConfigFile("/home/user/[...]");
in the app

and in the KCM you use
KConfigSkeleton(KDevelop::projectConfig())
to create a KConfigSkeleton object.

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

Ah, ok. Then obviously the global project config won't work...

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

> 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). But otherwise you could release a 
plugin without config GUI at first and without changing anything in the 
plugin release KCMs after that to configure the plugin. (Not that this 
scenario will happen very often, but I just want to show the independence.)

> 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

-- 
________________________________________________________
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/4f2a63f6/attachment.sig>