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

[Matthias Kretz]

I just realized that you answered to another thread than where I wrote a lot 
more details of how I think all this should look like. See 
http://lists.kde.org/?l=kde-core-devel&m=114406852231409&w=2 

On Tuesday, 9. May 2006 10:16, Tobias Koenig wrote:
> On Mon, May 08, 2006 at 11:41:13PM +0200, Matthias Kretz wrote:
> > Well we might want to have a standard way to figure out what dialog face
> > to use depending on the structure of the model:
> > one page -> plain dialog
> > flat list of (not too many) pages -> iconview dialog
> > tree of pages -> treelist dialog
>
> Well, personally I don't like 'magic' in the gui classes. What happens
> when the content of the dialog is filled with plugins?
> So if you have only one plugin installed the dialog looks completely
> different than when you have > 1 plugins installed.

You might have a point there, I'm not completely sure about the use cases. But 
I thought we might try to give the API user good/sensible defaults. And a 
good default for a plain list of pages is an iconview, while a good default 
for a hierarchy of pages is of course a treeview.

I think the Dialog class should do magic by default which can be overridden by 
the developer...

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

> We should have a class KPageModel which has a similar interface like the
> following:
>
> class KPageModel : public QAbstractItemModel
> {
>   public:
>     KPageModel( QObject *parent = 0 );
>     ~KPageModel();
>
>     // virtual methods reimplemented from QAbstractItemModel
>     ...
>
>     void addPage( QWidget *page, const QString &name,
>                   const QString &header, const QIcon &icon = QIcon() );
>
>     void addSubPage( QWidget *page, const QStringList &name,
>                      const QString &header, const QIcon &icon = QIcon() );
>
>     void removePage( QWidget *page );
> };
>
> // TODO: which index shall be used for an insertPage() method?
> (If we find a working index, we could adapt the interface to QTabWidget)

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
- insertPageBefore to allow for adding pages at arbitrary positions (in order 
to keep one sort order)
- access to the Qt::CheckStateRole
- emit a signal when a checkstate changed

As this is probably overkill for a KDialogPageModel the View class should 
rather take a QAbstractItemModel instead of reducing the usage to 
KDialogPageModel subclasses.

> So we have one model which can contain a single page, a list of pages
> and a whole tree.
>
> On the view side we should have a common base class KPageBaseView with
> the following interface:
>
> class KPageBaseView : public QWidget
> {
>   public:
>     KPageView( QWidget *parent = 0 );
>     ~KPageView();
>
>     void setModel( KPageModel *model );
>     KPageModel *model() const;
>
>     ...
> };
>
> and then the several subclasses
>
>   KSinglePageView    // shows only the first page of the model
>   KListPageView      // shows an icon list
>   KTreePageView      // shows a tree list
>   KTabbedPageView    // shows a tab widget with one tab for every page
>
> for convenience we can provide an additional class KPageDialog with
> the following interface:
>
> class KPageDialog : public KDialog
> {
>   public:
>     KPageDialog( KPageBaseView *view, KPageModel *model );
> };
>
> Comments, suggestions, objections?

Well, I don't really agree on those view classes as it differs too much from 
the pattern used in Qt4.
I'd rather see a
KJanusView - KJanusWidget combination which, by default, figures out the 
"face" automagically and provides a method to select a different "face" (like 
written in my other mail to core-devel).
Perhaps the "Janus" part of the class name is not a good idea, as I think many 
developers will not figure out what that is supposed to mean. OTOH 
KJanusWidget is not restricted to dialogs so using "Dialog" in the name is 
problematic.


I hope I didn't make too much of a mess with this mail. If you'd like to 
discuss this on IRC, #kde4-devel is probably a good place for that...

-- 
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/20060510/2572c037/attachment.sig>