[gst-devel] Re: [gst-cvs] thomasvs gstreamer: gstreamer/docs/random/ds/

[Ronald S. Bultje]

Hi,

I'll try to be somewhat clearer.

On Fri, 2004-07-09 at 10:20, Thomas Vander Stichele wrote: 
> On Thu, 2004-07-08 at 21:04, Ronald Bultje wrote:
> > On Thu, 8 Jul 2004, Thomas Vander Stichele wrote:
> > > On Thu, 2004-07-08 at 19:30, Ronald Bultje wrote:
> > > > On Thu, 8 Jul 2004, Thomas Vander Stichele wrote:
> > > > > + - make gst_bin_get_list virtual so subclasses can override it (e.g.
> > > > > +   gst-play which contains an internal thread not inside the bin that is
> > > > > +   gstplay)
> > > >
> > > > Isn't that a gstplay bug? If it pretends to be a bin, it should behave
> > > > like one.
> > >
> > [..]
> > > There are other reasons why a bin should be able to virtualize this
> > > function - if add and remove are virtualized, then so should get_list be
> > > since a bin can very well chose to override add and remove in such a way
> > > that they're not actually inside the bin.
> > 
> > Those are signallers, if I'm correct. So they're called to let the class
> > know that a child was removed/added. The child class is required to call
> > parent_class->add_element() in its own add_element() implementation, and
> > the same goes for remove.
>   /* vtable */
>   void          (*add_element)          (GstBin *bin, GstElement
> *element);
>   void          (*remove_element)       (GstBin *bin, GstElement
> *element);
> 
> these are the virtual functions.
> 
>   /* signals */
>   void          (*element_added)        (GstBin *bin, GstElement
> *child);
>   void          (*element_removed)      (GstBin *bin, GstElement
> *child);
>                                                                                 
> these are the signal handlers.
> 
> Did I miss something ?

No. ;). Their purpose is different.

As you might know, signals (element_added, element_removed) are
generally supposed to be called *after* an action has happened. The
purpose of those is to let associated objects know of a change in a
status quo so they can adapt in whatever way needed. Think gst-editor
adding a child in its GtkWidget of a GstBin if element_added is called.
Those are signallers, they're for third-party objects.

The virtual function table is what we're talking about here. Those are
filled in by child classes (so derived objects, which are a GstBin
themselves). The API documentation should state (it probably doesn't;
what a surprise) that the child class is supposed to call
parent_class->element_add() when its own implementation of element_add()
is being called. This means that in the end, the child table will always
be the one represented directly in the GstBin object, and thus you don't
need to virtualize get_child_list(). The purpose of this function is to
have the derived class know about the added child *before* it is added
to the actual GstBin struct. It can then feed the child with an
additional thread, scheduler or anything related so that the default one
of the actual GstBin will not be used (and this is what GstThread does).

Can you understand why gstplay would need to virtualize get_list() and
why it would need to differ in GstBin'ness behaviour? It's really all
unclear to me.

Ronald