[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] playground/bindings/kimono
From:       Richard Dale <rdale () foton ! es>
Date:       2007-04-07 19:09:17
Message-ID: 200704072009.18178.rdale () foton ! es
[Download RAW message or body]

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

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

-- Richard

_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]