[Kde-bindings] Questions on TODO list

[Arno Rehn]

Am Mittwoch, 7. Februar 2007 schrieb Richard Dale:
> On Wednesday 07 February 2007, Arno Rehn wrote:
> > Hi,
> >
> > I've just taken a look at the TODO list, but the first point I don't
> > really get:
> >
> > * Implement a way of ensuring instances with 'owners' like
> > QLayoutItem, QListWidgetItem, QTableWidgetItem, QWidget and QObject
> > are not garbage collected when they are no referenced in the C# code.
> > This matters if they have been subclassed in C#, as when they are
> > referenced again and a new C# wrapper instance is created it will
> > have lost the customised subclassing.
> >
> > What exactly do you mean? Maybe an example could do :-)
>
> TODO:
> * Make the TODO list comprehensible.. :)
>
> QObjects and QWidgets can have parents, and so they form a tree of objects.
> In C++ when a QObject is deleted, it deletes all its children. So one
> problem we have to solve is to ensure that when that happens in C#, we
> don't try to access methods on the children. On the other hand, you can add
> a child instance with a parent, but not keep any reference to the child in
> the C# code. For instance, in tutorial t14 this line doesn't keep any
> reference to the new QKeySequence, but it is owned by 'this' which is
> GameBoard a QWidget:
>
> new QShortcut(new QKeySequence((int) Qt.Key.Key_Enter), this,
> SLOT("Fire()"));
>
> So we need to keep a 'strong reference' (is that the correct term?)
> somewhere that will prevent the QKeySequence from being GC'd. Then when the
> parent GameBoard is deleted we need to remove the strong reference so that
> the QKeySequence can then be GCd ok.
Ah, now it's clear :-)
I just did a quick test with this line:
Connect(new QPushButton(), SIGNAL("clicked()"), qApp, SLOT("quit()"));
it gets called by an outside function which is a slot for another clicked() 
signal. If it was like you said, at the end of the function the instance 
created with 'new QPushButton()' would be destroyed by the GC and the 
destructor called. But when intercepting the calls with the transparent 
proxy, I don't get a call of the destructor, so the instance must be still 
existing, even without a reference.
I think by passing the GCHandle of the instance to somewhere outside Mono we 
get partial control over the memory of the instance. Only when we quit the 
app, Mono tries to free the memory, no matter if we had 'control' or not.
This is just my opinion, from what I've worked out there is no need for change 
the way of GC'ing
Did you make other experiences?

> How were the other things on the TODO list - does my description of
> Q_PROPERTYs make sense? That would be a good one to start with. Then we
> could set properties across dbus which would be very nice.
Yep, that was perfectly clear :-) . Will be quite simple to implement, I 
think. Looks like dbus is going to work really well and nicely soon.


-- 
Arno Rehn
arno at arnorehn.de