[Kde-bindings] Problem condition in Qyoto MethodCall

[Richard Dale]

On Monday 12 February 2007, Arno Rehn wrote:
> > [ ... cut ... ]
>
> Well, I've hacked a lot around in qyoto.cpp and changed the way we check if
> it's a contained instance or not: I've added a field to smokeqyoto_object
> called 'contained' and it is set up when the constructor was just called.
> This was necessary because sometimes the instance was already destroyed and
> we still wanted to get the parent of it. The new field is updated when the
> parent of the widget is changed because it is added to a layout, too.
> It works better now and up to t10 every tutorial works well. But with t11
> it keeps crashing and I can't figure out why it does so. Since I've created
> quite a mess, I don't want to check in what I have. I've attached a patch
> with all the changes, if you could take a look at it and tell me what you
> think...
I'm not sure if this is the best way to do it, as 'contained' seems to 
duplicate the function of 'allocated'. If an instance is 'owned' by another 
instance we can just set 'allocated' to false, and the Qyoto runtime won't 
delete it when the corresponding C# instance is garbage collected. What 
problem does it solve that the current scheme with the IsContainedInstance() 
function doesn't do? I don't think there's any hurry to solve the problem 
straight away, and it's best to keep experimenting like you're doing, but not 
actually commiting anything.

If we use the 'Transfer' data in the PyQt sip files we would need to change 
ownership when a method, or argument within a method was marked 
with 'Transfer'. So that data could either go into the smoke library runtime, 
as it would be useful for every language. Another way would be to add it as 
C# Attributes, in the 'SmokeMethod' one perhaps.

Qyoto seems a bit slow to me - I expected it to be faster than QtRuby, but 
it's actually slower at the moment. I tried running mono with the '--profile' 
option and there doesn't seem to be any obvious method that is hogging the 
time. The methodId caching scheme where the methodId was put inside the 
SmokeMethod didn't work, and so there seems to be something strange about how 
Attributes work. Now I've added caching of methodIds again, it didn't seem to 
make much difference to the speed.

-- Richard