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

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

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

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

-- Richard