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

[Matthias Kretz]

On Thursday, 11. May 2006 09:58, Tobias Koenig wrote:
> On Wed, May 10, 2006 at 08:19:35PM +0200, Matthias Kretz wrote:
> > I think the Dialog class should do magic by default which can be
> > overridden by the developer...
>
> 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

> > > At the moment I think making a difference between a KXXXPageView and a
> > > KXXXPageWidget doesn't make sense, since you don't need to reimplement
> > > your own model, but can fill KPageModel with data.
> >
> > If you can come up with a good KPageModel (I'd rather call it
> > KDialogPageModel to disambiguate the name from a model for pages in a
> > document, OTOH it is applicable for non-dialog situations as well) that
> > might be the case, but one of the strenghts of Qt's Interview IMHO is
> > that you can provide your own model, which is really flexible and easier
> > for some cases.
>
> 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?
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.

> > In order for the model to be sufficient for use in KSettings::Dialog the
> > following would be needed:
> > - addSubPage needs a way to specify the parent widget
>
> Do you really mean parent widget or parent item?

Well, how do you specify an "item"?

> 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.
And if you really want to use "name paths" then you don't need an addSubPage 
method at all.

> > - insertPageBefore to allow for adding pages at arbitrary positions (in
> > order to keep one sort order)
>
> Do we need an insertPageBefore and insertSubPageBefore here?

Example:
void insertPageBefore( QWidget* newPage, ..., QWidget* beforePage );

If beforePage is a subpage the new page will be on the same level. So I don't 
think the distinction is needed.

> > - access to the Qt::CheckStateRole
> > - emit a signal when a checkstate changed
>
> Ok, but then the addPage() calls need another parameter 'isCheckable',
> or?

right

-- 
C'ya
        Matthias
________________________________________________________
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/20060511/3548e020/attachment.sig>