Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
<!-- ##### SECTION Title ##### -->
|
|
|
|
GstObject
|
|
|
|
|
|
|
|
<!-- ##### SECTION Short_Description ##### -->
|
|
|
|
Basis for the GST object hierarchy.
|
|
|
|
|
|
|
|
<!-- ##### SECTION Long_Description ##### -->
|
|
|
|
<para>
|
|
|
|
GstObject provides a root for the object hierarchy tree filed in by the
|
|
|
|
GST library. It is currently a thin wrapper on top of
|
|
|
|
<classname>GtkObject</classname>, but eventually will be replaced by a
|
|
|
|
stripped down version of it. This will remove all the X dependencies from
|
|
|
|
the GST library, making it much more portably and generally useful.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
GstObject gives us basic refcounting and parenting functionality, though
|
|
|
|
it is possible that we could use <classname>GtkObject</classname>'s
|
|
|
|
equivalent functions. I'll probably use what I have now until I strip
|
|
|
|
down <classname>GtkObject</classname> to re-parent the hierarchy.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<!-- ##### SECTION See_Also ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
2000-12-28 21:42:23 +00:00
|
|
|
<!-- ##### MACRO GST_OBJECT_FLAG_LAST ##### -->
|
|
|
|
<para>
|
|
|
|
subclasses can use this value to start the enumeration of their flags
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
<!-- ##### STRUCT GstObject ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_FLAGS ##### -->
|
|
|
|
<para>
|
|
|
|
This macro returns the entire set of flags for the object.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj: Object to return flags for.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_FLAG_IS_SET ##### -->
|
|
|
|
<para>
|
|
|
|
This macro checks to see if the given flag is set.
|
|
|
|
</para>
|
|
|
|
|
2000-03-27 19:53:43 +00:00
|
|
|
@obj: GstSrc to check for flag in.
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
@flag: Flag to check for, must be a single bit in guint32.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_FLAG_SET ##### -->
|
|
|
|
<para>
|
|
|
|
This macro sets the given bits.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj: Object to set flag in.
|
|
|
|
@flag: Flag to set, can by any number of bits in guint32.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_FLAG_UNSET ##### -->
|
|
|
|
<para>
|
|
|
|
This macro usets the given bits.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj: Object to unset flag in.
|
|
|
|
@flag: Flag to set, must be a single bit in guint32.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_LOCK ##### -->
|
|
|
|
<para>
|
|
|
|
This macro will obtain a lock on the object, making serialization
|
|
|
|
possible.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj: Object to lock.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_TRYLOCK ##### -->
|
|
|
|
<para>
|
|
|
|
This macro will try to obtain a lock on the object, but will return with
|
|
|
|
FALSE if it can't get it immediately.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj: Object to try to get a lock on.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_UNLOCK ##### -->
|
|
|
|
<para>
|
|
|
|
This macro releases a lock on the object.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj: Object to unlock.
|
|
|
|
|
|
|
|
|
2001-01-31 20:27:00 +00:00
|
|
|
<!-- ##### MACRO GST_GET_LOCK ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj:
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_OBJECT_PARENT ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj:
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO GST_OBJECT_NAME ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@obj:
|
|
|
|
|
|
|
|
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
<!-- ##### FUNCTION gst_object_new ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@Returns:
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### FUNCTION gst_object_set_parent ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
@parent:
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### FUNCTION gst_object_get_parent ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
@Returns:
|
|
|
|
|
|
|
|
|
2001-01-31 20:27:00 +00:00
|
|
|
<!-- ##### FUNCTION gst_object_set_name ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
@name:
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### FUNCTION gst_object_get_name ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
@Returns:
|
|
|
|
|
|
|
|
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
<!-- ##### FUNCTION gst_object_unparent ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO gst_object_ref ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
2000-03-27 19:53:43 +00:00
|
|
|
@object: the object
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO gst_object_unref ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
2000-03-27 19:53:43 +00:00
|
|
|
@object: the object
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO gst_object_sink ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
2000-03-27 19:53:43 +00:00
|
|
|
@object: the object
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### MACRO gst_object_destroy ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
2000-03-27 19:53:43 +00:00
|
|
|
@object: the object
|
Re- set up the gtk-doc system. I'd managed to mutilate it a while back, but now it's fixed. I'll put a copy of the ...
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
2000-02-01 09:16:43 +00:00
|
|
|
|
|
|
|
|
2001-01-31 20:27:00 +00:00
|
|
|
<!-- ##### FUNCTION gst_object_save_thyself ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
@parent:
|
|
|
|
@Returns:
|
|
|
|
|
|
|
|
|
2000-12-30 16:13:17 +00:00
|
|
|
<!-- ##### FUNCTION gst_object_get_path_string ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
@Returns:
|
|
|
|
|
|
|
|
|
2001-01-31 20:27:00 +00:00
|
|
|
<!-- ##### FUNCTION gst_class_signal_emit_by_name ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@object:
|
|
|
|
@name:
|
|
|
|
@self:
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ##### FUNCTION gst_class_signal_connect ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@klass:
|
|
|
|
@name:
|
|
|
|
@func:
|
|
|
|
@func_data:
|
|
|
|
@Returns:
|
|
|
|
|
|
|
|
|
2001-01-07 17:09:28 +00:00
|
|
|
<!-- ##### SIGNAL GstObject::parent-set ##### -->
|
|
|
|
<para>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@gstobject: the object which received the signal.
|
|
|
|
@arg1: the new parent
|
|
|
|
|
2001-01-31 20:27:00 +00:00
|
|
|
<!-- ##### SIGNAL GstObject::object-saved ##### -->
|
|
|
|
<para>
|
|
|
|
Is trigered whenever a new object is saved to XML. You can connect to
|
|
|
|
this signal to insert custom XML tags into the core XML.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
@gstobject: the object which received the signal.
|
|
|
|
@arg1: the xmlNodePtr of the parent node
|
|
|
|
|