From: <MHL...@t-...> - 2003-04-03 09:41:32
|
Hi! In the process of creating the c++ bindings for gstreamer, I came across some issues about the GstObject API: - 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? - 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? - Objects of type GstObject can be in floated state. Is this useful for all derivations of GstObject? - Is it useful for all structs that currently inherit GstObject to have the data fields "name" and "lock"? All in all it seems that a great part of the functionality provided by GstObject is only used by GstElement and GstPad. I suggest moving this functionality into a further common base structure of GstElement and GstPad. Regards, Martin |
From: Benjamin O. <in...@pu...> - 2003-04-04 19:32:15
|
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. 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. > - 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". > - 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". > - 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. Hope that helps a bit. Cheers, Company |
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 |