KDE 4 Core Libraries major features

Matthias Kretz kretz at kde.org
Mon Apr 3 13:48:10 BST 2006

Hi Christian,

as this is only MHO about KJanusWidget and friends I'm CCing core-devel.

On Monday 03 April 2006 12:42, Christian Ehrlicher wrote:
> Since I'm relativly new to kde my only work on kdelibs is to make them
> compile on win32 and wipe out all qt3-stuff (and do some courois checkins
> from time to time ;) ).
> If you want, I can take a look at KJanusWidget... if you tell me what I
> have to do.

Well, I can't exactly tell you what to do, only where to start.

my motivation for the changes
When writing kdelibs/kutils/ksettings, especially the Dialog class, I had to 
circumvent the limitations of KJanusWidget and add new methods to it in order 
to achieve what I wanted. The task could be described with the following 
(abstract) use case:
- collect dialog pages that come with some kind of hierarchy information
- if there's only one dialog page
  -> create a simple dialog showing only that page
- if there's a flat hierarchy of pages
  -> create a dialog with an iconview on the left to select the pages
- if there's a tree hierarchy of pages
  -> create a dialog with a treeview on the left to select the pages

- some time later new pages need to be added (because the user activated a new 
component); too avoid confusion the pages should appear always at the same 
position in the treeview (or iconview)

the problems with KJanusWidget
in short: the class does too much while providing too little flexibility
1. You cannot add pages and then later decide what presentation you want, the 
"Face" has to be decided on on construction. (Feels like the Face enum 
selects a different class with the same methods, and those methods don't even 
make sense for all Face settings. I think it'd be more logical if there were 
a common base class and subclasses to implement those Faces - but see below 
for another idea.)
2. The creation of tree hierarchies has a cumbersome API. One has to identify 
pages using names and stringlists of those names.
3. Because of (2.) there's no way to insert pages at a predefined position. 
You can only append pages to the end of a level. Example:
There's no way to create
without creating a whole new dialog. (which is what KSettings::Dialog does)

Idea for a new KJanusWidget
short version: use Qt4's Interview
-> KJanusView and KJanusWidget split
1. identify needed roles to extend Qt::ItemDataRole
1.a) The model returns all data to let KJanusView see whether a navigation is 
needed and whether that needs to be a TreeView. (It should always be possible 
to override no nav. with IconView and TreeView representation and IconView 
with TreeView.)
1.b) The model returns data to fill the navigation. Most of the predefined 
roles can be used for that, simply by setting the model on the navigation 
I think especially the possibility to use the Qt::CheckStateRole is 
interesting to make KSettings::Dialog more usable.
1.c) Additional roles could be:
PageWidgetRole  The widget to be shown in the dialog
PageHeaderRole  The header above the page widget

2. Write an (abstract?) base class to ease development of dialog models and to 
be used internally in KJanusWidget.

3. Write KJanusView that can use either an IconView or a TreeView to display 
the navigation and that shows the according widget using the PageWidgetRole 
on selection of a page in the view.

4. Write KJanusWidget that has an interface like the current KJanusWidget but 
uses KJanusView internally and that doesn't necessarily decide on the Face on 

Matthias Kretz (Germany)                            <><
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/20060403/0dc10af4/attachment.sig>

More information about the kde-core-devel mailing list