From: <MHL...@t-...> - 2003-04-05 11:08:57
|
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 > an > 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 > there. 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 on gstreamer-0.7. > > - 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 > little > 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 > the > > 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 and elements. Cheers, Martin |