Would be nicer if one could just supplement the generic template
from the element template though.
Also, I would really have liked to just add those sections from the
pads template into the element templet directly (so I can cater for
src template caps == sink template caps), but that didn't seem to
work.
Create a tools directory for an application. Add source code
stubs to allow the project to compile and pass make distcheck.
Add notes in source code to tell the user how to create plugin
or app code using the other -maker scripts.
This is a replacement for gst-template that creates an entire
autotools project (customized to package name), and populates
it with the source for a GStreamer plugin (but no plugin features,
those come from gst-element-maker). Fixes: #665727.
Move not working templates to a separate variable to highlight the fact that
they need more work. These need at least the class and type fields filled.
This allows using capitalized acronyms in class names, so using
"AVC_src" on the command line will create filename gstavcsrc.c,
class name GstAVCSrc, and symbol names gst_avc_src_*.
Add a script that creates elements based on any of the GStreamer
base classes. It isn't very user friendly at the moment, one
needs to edit the script to make it work properly. Each base class
has a template file describing what to put into the constructed
element. Eventually, these templates should be moved to reside
with the base class source and installed to a well-known directory,
where an installed script could find them.
The template files use the .c ending so editors know they are C
source, but gst-indent doesn't handle them correctly. So they
need to be committed with -n. Ugh. I'll try to figure out a fix
for that soon.
