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

Arno Rehn arno at arnorehn.de
Mon Mar 26 19:46:01 UTC 2007


Am Montag, 26. März 2007 schrieb 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.

> 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.
Ah ok, now I see. Thanks for the explenation ;-)

> > > > * 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.
If we just want to have a look at all the types inside an assembly, we can use 
monop / monop2. If we want to generate documentation we can use monodocer 
(but the generated documentation is rather bad, in my opinion. MSDN does it a 
lot better).


-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list