KJanusWidget and Model-View (was: Re: KDialog / KDialogBase)

[Tobias Koenig]

On Thu, May 11, 2006 at 11:24:58AM +0200, Matthias Kretz wrote:
> On Thursday, 11. May 2006 09:58, Tobias Koenig wrote:
Hi Matthias,

> > Ok, so we just have to find a way how to overwrite it, maybe we can add
> > another Face type 'Auto' which does exactly this.
> 
> How about:
> 
> m_view = new KJanusView( parent );
> m_view->setModel( m_pageModel );
> // m_view will use the face it thinks works best
> m_view->setFace( KJanusView::TreeFace ); // now it will display a tree even if
> // the model contains only a list
Looks good.

> > IMHO we need these separation between the single views to avoid such
> > strange method like 'setRootDecorated(bool)' in current KJanusWidget,
> > which does only work when the Tree face is selected. That really smells
> > bad!
> 
> Why would we need that method at all? Why should the page navigation show an 
> open/close sign on the root?
Well, it's part of API of the current KJanusWidget, so we have to
provide something similar somehow.

> Regarding face specific settings: I think those should be moved into the 
> model. After all the model provides a lot of roles for determining the 
> presentation of the data.
No, it should not be moved into the model but the view, model is about
data ;)
But we should allow the developer to replace the QAbstractItemView on
the left side by his own implementation, so he can replace the delegate
if he wants custom drawing.


> > Do you really mean parent widget or parent item?
> 
> Well, how do you specify an "item"?
With item I meant the entry in the icon/tree list

> > The parent item is defined by the name path.
> 
> Which is something I didn't like from the KJanusWidget API and why I think 
> providing a model yourself instead of inserting pages using such an API is 
> easier and more flexible.
It's not easier, because every developer would have to create it's own
model for basic things, and creating a treemodel is not that easy.

But I though about a new approach.

We could define a new class KPageItem with the following API

  KPageItem( QWidget *widget, const QString &name );

  void setIcon( const QIcon& );
  void setHeader( const QString& );
  void setCheckable( bool );

which encapsulates an entry of the KPageModel. The 'name' parameter is a
string which contains the path of the item, with '|' as delimiter.

So you would add a new page like this:

  KPageWidget *pageWidget( this );

  KPageItem *item1 = new KPageItem( myWidget, i18n( "Folder|Music" ) );
  item1->setHeader( i18n( "My Music" ) );
  item1->setIcon( QIcon( "music_folder" ) );

  pageWidget->model()->addPage( item1 );

  KPageItem *item2 = new KPageItem( yourWidget, i18n( "Folder|Images" ) );
  item2->setHeader( i18n( "My Images" ) );
  item2->setIcon( QIcon( "image_folder" ) );

  pageWidget->model()->insertPage( item1.name(), item2 ); // insert before item1

and the resulting tree looks like this:

 - Folder
   |
   +- Images
   |
   +- Music

By using a QString with '|' separator we can omit the extra method with
an QStringList argument and existing code can easily be converted by
using QStringList.join("|").

> And if you really want to use "name paths" then you don't need an addSubPage 
> method at all.
Right :)

Ciao,
Tobias
-- 
Separate politics from religion and economy!
The Council of the European Union is an undemocratic and illegal institution!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060512/095ddade/attachment.sig>