[Bug 695089] Cannot override certain functions in GstBase

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=695089
GStreamer | gst-python | 1.0.5

Thibault Saunier <tsaunier> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
CC| |***@gnome.org
Ever Confirmed|0 |1

--- Comment #3 from Thibault Saunier <***@gnome.org> 2014-06-09 09:20:15 UTC ---
The bug is that both classes GstBaseSink and GstElement have a virtual method
with the exact same name (->query). The introspection can't really know which
one we want to override when we set the do_query vmethod.

We might do some trick in the override so that we have do_base_sink_query and
do_query or something like that?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=695089

Philip Withnall <***@tecnocode.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@tecnocode.co.uk

--- Comment #4 from Philip Withnall <***@tecnocode.co.uk> ---
This is also a problem with the `fill` vfuncs on GstBaseSrc[0] and
GstPushSrc[1] as seen on [2].

[0]:
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseSrc.html
[1]:
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstPushSrc.html
[2]:
https://stackoverflow.com/questions/45497507/using-pygi-how-can-i-override-a-virtual-method-from-a-gobject-class-that-has-th

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=695089

--- Comment #5 from Thibault Saunier <***@gnome.org> ---
I see two possible solutions:
* Figure out a way in gst-python, not sure how bet I bet we can hack
something around the issue
* Add new vmethod on the basclass to differentiate the names, and deprecate
the old ones (or not).

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=695089

Danilo <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #6 from Danilo <***@gmail.com> ---
I'm trying to understand: the method _setup_vfuncs in MetaClassHelper class in
types.py file first get the base classes in order using __mro__ and take just
the first class that has a virtual method with the name of the overwriting
method. After that, it checks if there are virtual methods with the same name
more deeply in another base class, and if found, just give up. But when a class
inherits another one, the methods of the base class with the same name as the
methods of the derived class are overwritten. Hence, why check for this
ambiguity, or better, it is really a ambiguity?

More cleary, is really necessary run find_vfunc_conflict_in_bases (line 108 at
types.py)?

Btw, I removed this check as workaround and worked (at least in my case).

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=695089

--- Comment #7 from Thibault Saunier <***@gnome.org> ---
In the GObject case it is and ambiguity as if you have BClass subclass of
AClass and both define AClass.some_vmethod and BClass.some_vmethod, those are
different vmethods (different offset in the class structures etc) and calling
((AClass*) class_struct)->some_vmethod is different than calling (on the same
structure) ((BClass*) class_struct)->some_vmethod.

In the case of GstBaseSink::query, PyGobject can't know what a `do_query` wants
to override, GstBaseSink::query vmethod or GstElement::query, and overriding
one or another would lead to different behaviour.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=695089

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #8 from GStreamer system administrator <***@gstreamer.net> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/gstreamer/gst-python/issues/1.