mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-06 01:19:38 +00:00
b338085a29
Original commit message from CVS: * docs/design/part-MT-refcounting.txt: * docs/design/part-conventions.txt: * docs/design/part-gstobject.txt: * docs/design/part-relations.txt: * docs/design/part-standards.txt: * gst/gstbin.c: (gst_bin_add_func), (gst_bin_add), (gst_bin_remove_func), (gst_bin_remove), (gst_bin_iterate_recurse), (gst_bin_get_by_name), (gst_bin_get_by_interface), (gst_bin_iterate_all_by_interface): * gst/gstbuffer.h: * gst/gstclock.h: * gst/gstelement.c: (gst_element_class_init), (gst_element_change_state), (gst_element_set_loop_function): * gst/gstelement.h: * gst/gstiterator.c: * gst/gstobject.c: (gst_object_class_init), (gst_object_ref), (gst_object_unref), (gst_object_sink), (gst_object_dispose), (gst_object_dispatch_properties_changed), (gst_object_set_name), (gst_object_set_parent), (gst_object_unparent), (gst_object_check_uniqueness): * gst/gstobject.h: Docs updates, clean up some headers. Free iterators in GstBin. GstObject is now looking good.
81 lines
2.2 KiB
Text
81 lines
2.2 KiB
Text
Documentation conventions
|
|
=========================
|
|
|
|
Due to the potential for exponential growth, several abbreviating conventions will be used throughout this
|
|
documentation. These conventions have grown primarily from extremely in-depth discussions of the architecure in IRC.
|
|
This has verified the safety of these conventions, if used properly. There are no known namespace conflicts as long as
|
|
context is rigorously observed.
|
|
|
|
Object classes
|
|
--------------
|
|
|
|
Since everything starts with Gst, we will generally refer to objects by the shorter name, i.e. Element or Pad. These
|
|
names will always have their first letter capitalized.
|
|
|
|
Function names
|
|
--------------
|
|
|
|
Within the context of a given object, functions defined in that object's header and/or source file will have their
|
|
object-specific prefix stripped. For instance, gst_element_add_pad() would be referred to as simply _add_pad(). Note
|
|
that the trailing parentheses should always be present, but sometimes may not be. A prefixing underscore (_) will
|
|
always tell you it's a function, however, regardless of the presence or absence of the trailing parentheses.
|
|
|
|
#defines and enums
|
|
------------------
|
|
|
|
Values and macros defined as enums and preprocessor macros will be referred to in all capitals, as per their
|
|
definition. This includes object flags and element states, as well as general enums. Examples are the states NULL,
|
|
READY, PLAYING, and PAUSED; the element flags LOCKED_STATE , and state return values SUCCESS, FAILURE, and
|
|
ASYNC. Where there is a prefix, as in the element flags, this is usually dropped, and implied. Not however that
|
|
element flags should be cross-checked with the header, as there are currently two conventions in use: with and without
|
|
_FLAGS_ in the middle.
|
|
|
|
Drawing conventions
|
|
===================
|
|
|
|
When drawing pictures the folowing conventions apply:
|
|
|
|
objects
|
|
-------
|
|
|
|
Objects are drawn with a box like
|
|
+------+
|
|
| |
|
|
+------+
|
|
|
|
|
|
pointers
|
|
--------
|
|
|
|
a pointer to an object.
|
|
+-----+
|
|
*--->| |
|
|
+-----+
|
|
|
|
an invalid pointer, this is a pointer that should not be used.
|
|
|
|
*-//->
|
|
|
|
|
|
elements
|
|
--------
|
|
|
|
+----------+
|
|
| name |
|
|
sink src
|
|
+----------+
|
|
|
|
pad links
|
|
---------
|
|
|
|
-----+ +---
|
|
| |
|
|
src--sink
|
|
-----+ +---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|