[Kde-bindings] Few questions on Qyoto TODO list, again

[Richard Dale]

On Monday 26 March 2007, Arno Rehn wrote:
> Am Montag, 26. März 2007 schrieb Richard Dale:
> > On Sunday 25 March 2007, Arno Rehn wrote:
> > > Hi,
> > >
> > > again I have a few questions on the TODO list of Qyoto:
> > >
> > > * Implement QTableModel and QListModel as subclasses of
> > > QAbstractTableModel. Special case the RowCount(), ColumnCount(),
> > > Data(), SetData(), Flags(), InsertRows(), InsertColumns(),
> > > RemoveRows() and RemoveColumns() methods. These classes can't be
> > > created from C# code, and only need dummy constructors with a Type
> > > arg so CreateInstance() can use it to create C# wrapper instances.
> >
> > Yes, that's right. In the view api a model is returned as a
> > QAbstractItemModel which only has pure virtual functions in the Smoke
> > lib. It is a QObject and so we can use QMetaObject::className to get the
> > correct name in
> > resolve_classname() and construct them via the dummy constructor. I must
> > have found out about this when I was getting a particular Qt example to
> > work, but I don't say which one the QtRuby ChangeLog unfortunately.
> >
> > >  - What is the use of these two extra classes? They don't exist in
> > > the 'original' Qt API either, so why would we want to implement these?
> > > We could use QStandardItemModel as well, it would support everything
> > > needed, I think.
> >
> > I don't think they are subclasses of QStandardItemModel, but are direct
> > subclasses of QAbstractItemModel. So I don't think casting them to a
> > class which they aren't an instance of in C++ is a good idea.
>
> I still don't get your point. What is the actual use of having QTableModel
> and QListModel as additional subclasses? Imagine I would want to write my
> own ListModel - then I'd need to subclass QAbstractListModel (or
> QAbstractItemModel) and then work with that one. Fine. For what do I need
> QListModel then? If I don't need any special features, I can safely use
> QStandardItemModel. So I see no problem here. Could you maybe give an
> example?
They're subclasses of QAbstractTableModel which can't be instantiated. So if 
you make a call on a method in QTreeWidget or QListWidget or their 
superclasses which returns a model the code has to return something. And it 
can't just return a random class like QStandardItemModel instead of the 
proper class. We can mark them as 'internal' - I believe C# has a way of 
marking code that is not to be used directly by application code using a 
package. Both QTableModel and QListModel can use the same C functions, and 
the C++ pointers can be cast to QAbstractTableModels before calling the 
methods and it won't invoked the pure virtual method in that class, but the 
ones hidden in the private classes.


> > > * Write a tool in C# to introspect on the Smoke library like rbqtapi.
> > >
> > >  - Should this tool only support the types and methods implemented in
> > > Qyoto or all the types in the Smoke library?
> >
> > I suppose the ruby one returns everything, and also shows the C++ types.
> > But as C# is much more similar to C++ (eg it has method overloading), it
> > might be possible to show the output as C# calls and only show those
> > implemented in Qyoto.
>
> Good - then this can be done with reflection, I think, and would make
> things a whole lot easier.
Yes, come to think of it we don't need to look at the smoke lib at all because 
the Qyoto bindings have all the type info in them. It isn't the same in 
qtruby. Maybe there is a tool we can use already - perhaps monodoc would work 
well with Qyoto I haven't tried it.


> > > * Write a dbusxml2cs tool based on the C++ one
> > >
> > >  - This is somewhat difficult, because it makes use of private headers
> > > of Qt. These headers aren't installed, so we would have to copy the
> > > needed things out of the files into dbusxml2cs. That would make
> > > maintaining of the code hard, though, as the private headers are
> > > changed quite often. Easiest would be to completely rewrite/port it to
> > > whatever language, obvious would be C#, of course.
> >
> > Well I don't think that is very different from what we had to do to
> > implement the csrcc and uics tools. I would rather steal the Qt C++ code
> > than start again. But I don't think this tool is very important, and it
> > might not even work with C# as it would depend on C++ specific compile
> > time features. Maybe it isn't worth bothering with, especially for a
> > first release.
>
> I've looked a bit over the code and there are some macros and specific
> qt-casts used in the generated code, but nothing that couldn't be done in
> C#. But your right, for a first release it's probably not worth bothering
> with.
Yes, ok lets leave it out for now. 

-- Richard