[Kde-bindings] playground/bindings/kimono

[Arno Rehn]

Am Samstag, 7. April 2007 schrieb Richard Dale:
> On Saturday 07 April 2007, Arno Rehn wrote:
> > 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#).
>
> Ah, ok I didn't know about QTextDocument.DocumentLayout() - does that mean
> there is another internal Qt class there? I'll have a look at the sources
> to see what is going on.
Yes, there seem to be some more internal Qt classes, e.g. QMessageBox seems to 
make use of some internal button classes.

> > 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.
>
> OK, as long as it works for QTableWidget and QListWidget, and the
> application writer isn't confused about what the classes are for, which an
> 'Internal' name would solve, that sounds fine to me.
Ok, I'll change that.

-- 
Arno Rehn
arno at arnorehn.de