Ownership transfer issues with gstreamer about lgi HOT 5 CLOSED

Umm. Looks like gstreamer wants transfer of the input arguments, which is generally not recommended for use with gobject-introspection (and unsupported by lgi call marshalling code :-( ).

There is a possible workaround, adding overrides for all methods which consume the input arguments, something similar to
https://github.com/pavouk/lgi/blob/master/lgi/override/Pango.lua#L130

In the long term (I hope during this summer), I plan to have major rewrite of the marshaling system, so these atrocitities should be possible to handle better using overrides. I'm not sure if it is worth the effort to add ugly workarounds into Gst overrides roght now, given the longer-term plan...

from lgi.

Turned out that implementing transfer!=none on input objects in generic marshaller was much easier than I originally thought. Pushed to master, I don't see any warnings from gstreamer samples any more.

from lgi.

Turned out that implementing transfer!=none on input objects in generic marshaller was much easier than I originally thought. Pushed to master, I don't see any warnings from gstreamer samples any more.

from lgi.

gstreamer ownership is really thorny. There is only one thing which is sure: 0.10 is total failure with regard to gobject integration (gstminiobject, custom refsink, misunderstood transfer/floating interactions etc). It seems that all these issues are fixed in 0.11, but it is unfortunately not in widespread use yet, so we'll probably have to deal with 0.10.

I agree that the (transfer full) annotation on return types returning floatings are incorrect. But it seems to me that the annotations (transfer full) on input arguments are incorrect too, but those two incorrectnesses basically work together, resulting in some (albeit a bit fragile) equilibrium - at least after my patch allowing tranfer-full on input arguments the samples seem to run well. Please let me know if you don't agree with this.

As for your attempts to override callable information, I've just one word: congrats. I'm amazed that someone was able to understand that ugly twisted code of mine. The idea of __newindex on callable is very neat.

However, given that a) 0.11 seems to have fixed these issues consistently and b) I'm in the middle of the redesign of the whole callable/marshal/repo machinery, I'm inclined to leave things as is for now (unless some other problems with current scheme appears).

BTW: there is basically no difference between Buf:add_watch() and Buf._method:add_watch(). _method, _property etc serve mainly for categorization (and easier implementation of lazy loading from GI), but when accessed, they behave the same (Buf.add() has precedence before Buf._method.watch). There is another important effect of categorization - slowdown during symbol lookup :-(, and thus for 99% the category table will go away.

from lgi.

Lol... thanks

I missed your follow-up before I had done mine..... and then deleted it before I saw your response.

lgi might have accreted some overcomplexity in some places but I appreciate the complexity of gi and the task at hand. I like hacking on this and I really like overall what you've done here. I could go just go off and use lgob or some other wrapper thing :), but I prefer lgi.

from lgi.