standardized preferences dialog

[Matthias Kretz]

Hi,

after many months I finally came up with something that I think might work. A 
few details are still not finished and I didn't think of integrating plugin 
selection yet, but I guess the ideas, that danimo helped me with, should work 
out.

Here's what I wrote down:

KPrefsDialog using KCMs (outline):
----------------------------------

The program provides KCMs with their .desktop files installed in 
$KDEDIR/share/services to make it possible for KTrader to handle them and/or 
installed in $KDEDIR/share/applnk/Settings so they appear in KControl.

When the preferences dialog is called kdelibs/kutils/kcmultidialog is used to 
embed the KCMs. The program doesn't have to know what KCMs to use but just 
asks KTrader for the modules for this program.

The KCMultiDialog is constructed by the KPrefsDialog. This class searches for 
the KCMs that need to be added. For notifying the right objects that the 
configuration has changed a KPrefsDispatcher object would connect the dialog 
and the objects.

Optionally (or always?) I want to have only one preferences dialog open per 
application. If I open up the dialog and it's already present the existing 
dialog should be raised. This would only be possible over process boundaries 
using DCOP, but could easily be done if e.g. Konqueror shows two instances 
that are in the same process.

The .desktop file entries:
--------------------------

Name, Comment, Icon, X-KDE-ModuleType, X-KDE-Library, X-KDE-FactoryName are 
used like for normal KControl KCMs.

Type=Service and ServiceTypes=KPrefsModule

X-KDE-ParentApp is set to the application name this module belongs to. (e.g. 
KView part and plugins would specifiy "kview" while the kmailpart would also 
specify "kmail" - the kontact case is a special one and is handled 
different).

X-KDE-PrefsParent is set to the internal name of the app/part/plugin this KCM 
belongs to. (e.g. "kview", "kviewviewer", "kviewpresenter" ...)

How to define which KCM belongs to what apps:
---------------------------------------------

The KCMs .desktop file is installed as Type=Service in 
$KDEDIR/share/services/kprefs. By looking at the ServiceType (value 
"KPrefsModule") we can find all KCMs. You can find all the KCMs belonging 
especially to one application using KServiceGroup::childGroup( "appname" ); 

In the case of Kontact you have different KParts providing the programs 
functionality, but since the program knows the KParts it's using it can query 
for KCMs with the X-KDE-PrefsParent set to the according KParts.

Construction of the Dialog:
---------------------------

KPrefsDialog constructs a KCMultiDialog and feeds it the KCModuleInfo objects 
that are created from a KTrader query. For an application like KView the 
KPrefsDialog would ask the trader for "ServiceTypes=KPrefsModule" with the 
constraint "X-KDE-ParentApp=kview". The list of KService objects is then used 
to create KCModuleInfo objects.

I'm in need of a way to tell the position of the KCM in the dialog. I want it 
to be possible to create a tree of pages in the KDialogBase. The groups() 
method of KCModuleInfo is a good candidate for that. But so far the groups() 
value was created by looking at the directory tree of the .desktop file. If 
the X-KDE-Groups field is set the groups() value is set to that. If you want 
to pass a list you need to separate the entries with a semicolon.

The case where your only KTrader constraint is the X-KDE-ParentApp is the easy 
one. But if you want to create a dialog for an app like Kontact your 
constraint is "X-KDE-ParentApp=kontact or X-KDE-PrefsParent=kmailpart or 
X-KDE-PrefsParent=korgpart" (I'd need to look at the KTrader syntax to write 
a real one).

For Konqueror the problem is again another one. I'd say the "Configure 
Konqueror..." action should open up a dialog with the pages included like it 
is currently. You wouldn't want to merge in the current KPart since that 
would just confuse the user when the dialog changes without the user 
requesting it explicitly. So we need a new Action to configure the current 
part (and its plugins). Optimally this Action is inserted automatically (I 
need to see if that is possible), or Konqueror needs to handle it (which is 
probably also not a bad idea).

And another case: Say my KViewCanvas component (not a KPart BTW) would ship 
with a KCM. Then every program using the KImageViewer::Canvas interface would 
like to be able to show the config dlg of the component it's using. According 
to the Application this would either be merged into the main KPrefsDialog or 
a special button to configure the canvas would open up a KPrefsDialog with 
the KCM of that component. So what I need is a ctor for KPrefsDialog to get a 
dialog for a list of X-KDE-PrefsParent entries. The problem: The program 
doesn't know what component it's going to get when it asks for a 
KImageViewer::Canvas so it doesn't know the name to use for the constraint.

Dispatching
-----------

To (perhaps/hopefully) solve above problem and to tell the relevant parts of 
the program that their configuration has changed a dispatcher is needed.

The dispatcher is a globally available object (either a singleton, KGlobal:: 
thingie or a child of KApplication) where the MainWin, KParts and Plugins 
register with their instanceName and a slot to be called when the 
configuration of one of their KCMs has been changed and applied.


PS: There's a lot of code duplication in this area currently, but I've seen 
nothing so far that could solve my problems. I don't want to force my ideas 
on KDE - I want a solution for KView that helps other application developers, 
too. I hope together we may find the right solution that's fits us all :-)

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
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: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030428/5841c733/attachment.sig>