KJanusWidget and Model-View (was: Re: KDialog / KDialogBase)
tokoe at kde.org
Thu May 11 08:58:57 BST 2006
On Wed, May 10, 2006 at 08:19:35PM +0200, Matthias Kretz wrote:
> 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
Ahh ok, thanks!
> 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...
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.
> > 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
> 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?
The parent item is defined by the name path.
> - insertPageBefore to allow for adding pages at arbitrary positions (in order
> to keep one sort order)
Do we need an insertPageBefore and insertSubPageBefore here?
> - access to the Qt::CheckStateRole
> - emit a signal when a checkstate changed
Ok, but then the addPage() calls need another parameter 'isCheckable',
> As this is probably overkill for a KDialogPageModel the View class should
> rather take a QAbstractItemModel instead of reducing the usage to
> KDialogPageModel subclasses.
> 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...
Ok, I'll be online on friday again.
Separate politics from religion and economy!
The Councile of the European Union is an undemocratic and illegal institution!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the kde-core-devel