Am 04.04.2003 21:31 schrieb(en) Benjamin Otte:
> Ok, I'll try to answer as good as I can, please correct me if I tell
> something wrong.
> On Thu, 3 Apr 2003, Martin Schulze wrote:
> > - GstObject has a data field "parent". This field seems to be used only
> > for GstElement and GstPad. Other structures don't seem to have a
> > clear container<->child relationship. Is this right?
> You're missing at least clocks and schedulers. Clocks usually belong to
> element (or a scheduler - I don't know about clocks, but they belong
> somehere) and schedulers belong to their base element. So it makes sence
Clocks are referenced by elements and schedulers equally. And it looks like
they are shared between different elements/schedulers so they don't seem to
have a parent. Maybe I'm missig something.
> I'm not aware of any subclass where it does not make sence to have a
> parent field. Those should probably be fixed to descend from GObject.
The parent field is not used anywhere but in GstPad and GstElement.
Running 'grep "gst_.*_set_parent" gst/*.c' will show you what I mean.
However, I don't know whether it might become useful for clocks,
schedulers and the other types to have a parent field at some point;
so I'm not the one to judge what other types should inherit from
GObject rather than GstObject. I think someone with a deeper insight
should have a close look at this before some stable branch is based
> > - There is a function gst_object_destroy() that forces the destruction
> > of the passed object. Is this intended to work at any time? For
> > GstElement/GstPad? For other types? Is the parent notified about
> > the destruction?
> I think this is cruft left over from the glib/gtk 1.2 days. After a
> grepping it's only used in old examples and test. So I vote for "remove
> it, we're properly refcounting".
Yes, I totally agree.
> > - Objects of type GstObject can be in floated state. Is this useful for
> > all derivations of GstObject?
> I think it's useful for every object that can have a parent. So the
> obvious answer would be "yes".
Again, the parent field is only used by GstPad and GstElement :-)
> > - Is it useful for all structs that currently inherit GstObject to have
> > data fields "name" and "lock"?
> I'm not sure if we have a _get_scheduler_by_name function and if it would
> make sense there, but IMO it makes sense for the rest of objects I can
> think of, because they can all appear in greater numbers and a
> _get_by_name is useful.
> I don't know what locks are used for.
Running "grep GST_LOCK gst/*.c" it lock like locks are used for clocks