[Kde-bindings] playground/bindings/kimono

[Arno Rehn]

Am Samstag, 7. April 2007 schrieb Richard Dale:
> On Friday 06 April 2007, Arno Rehn wrote:
> > SVN commit 651139 by arnorehn:
> >
> > * Added more helper classes for abstract base classes which are returned
> > by public methods.
> > * Fixed little bug in qdbus/chat/chat.cs.
> >
> > CCMAIL: kde-bindings at kde.org
> >
> >
> >
> >  M  +3 -0      ChangeLog
> >  M  +1 -1      examples/qdbus/chat/chat.cs
> >  A             gui/QAbstractButtonHelper.cs
> >  A             gui/QAbstractItemDelegateHelper.cs
> >  A             gui/QAbstractItemViewHelper.cs
> >  A             gui/QAbstractProxyModelHelper.cs
> >  A             gui/QAbstractTextDocumentLayoutHelper.cs
> >  M  +11 -0     handlers.cpp
> >  M  +146 -0    qyoto.cpp
>
> I'm not clear what these classes are for - what problem do they solve? I
> thought we needed just a couple of classes corresponding to the Qt internal
> QTableModel and QListModel classes so we could call all the methods in the
> QTableWidget and QListWidget classes. Also, if they are 'internal only' and
> not in the public Qyoto api, then I think they should be called
> '..Internal' rather than '..Helper'.
There are a couple of other classes that are abstract but still the return 
type of some methods. For example QTextDocument.DocumentLayout() returns a 
QAbstractTextDocumentLayout. Of course the call had crashed before because 
the class is abstract and therefore no instances of it can be created. Same 
goes for the other QAbstract*Helper classes I've added. But you're right, 
they should rather be called ...Internal than ...Helper and if possible 
marked with "internal" (I'm not sure if there is such a keyword in C#).

Regarding the QTableModel and QListModel stuff: I don't think we need these as 
they are not the return type of any method (grepping through the sources I 
didn't find any). Furthermore the only difference between a 
QAbstractItemModel and QAbstractList/TableModel is that 'index()' is 
reimplemented. But if I understand the concept of virtual methods correctly 
that shouldn't bother us because in the C++ code, when we call 
((QAbstractItemModel*) o->ptr)->index() the right 'version' is chosen 
automatically. So I don't see a reason for creating a QTableModel or 
QListModel.

-- 
Arno Rehn
arno at arnorehn.de