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

[Arno Rehn]

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?

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

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


-- 
Arno Rehn
arno at arnorehn.de