Not only this will make colored output work on old terminals and console
as well, terminals can theme the actual colors this way to make it fit
with their different themes this way.
Let's make the output a bit pretty to read. The colored output can be
disabled with `--no-colors` option or by setting `GST_INSPECT_NO_COLORS'
env (to any value).
The chosen colors are based on the popular Solarized theme, which is
targeted for both dark and light backgrounds.
Note:
* We only support true colors. If the terminal doesn't signal support for
that via 'COLORTERM' env, we disable colored output.
* We don't add colors to --print-plugin-auto-install-info output, as
that's meant for machines, not humans. Not only machines don't care
about beauty, the existing ones will likely not expect colors and choke
on it and we'll get angry mob at our doors.
[1] https://ethanschoonover.com/solarized
When printing info about a specific plugin, there is no need to prefix
some of the details with plugin's name. It's not only redundant but also
inconsistent and makes the task of adding consistent coloring to the
output (which we'll do in a follow patch), harder.
This emulates the default behaviour of git help pages, and also fixes
a bug on macOS where `less -F` doesn't display anything at all when
the output is shorter than one terminal screen.
Also moved the DEFAULT_PAGER define to after the includes, because
it's an unprefixed define.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/330
Rename print_element_features() to print_feature_info() and move the code that
handles the ElementFactory there. This simplifies the calling code and improves
readability.
Also don't leak the features for other factories.
Don't use templates for the man pages, the API version change is a rare
event, so it's not really worth keeping in place the "sed" boilerplate
to have it set at build time.
Shipping the final man pages directly also makes it easer to install the
man pages with meson (in a future commit).
Note that now all the occurrences of the programs names have the API
version as a suffix.
Traditionally the example command lines looked like:
gst-launch ...
Now they look like:
gst-launch-1.0 ...
This reflects the actual programs names and makes it easier to copy and
paste the example commands.
Also, the .gitignore file is adjusted not to ignore the final man pages
anymore.
You may need to clean your src/build directory before pulling in this
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=773917
When a line starts with a single quote it's treated in a special way by
man, which may result in paragraphs of the man page not rendered by the
man pager, so just avoid that.
A possible solution could have been to escape the singe quote with
a \(cq sequence but this is rather unreadable, instead the text has been
reformatted to have the problematic quoted 'ppc' string on the previous
line.
https://bugzilla.gnome.org/show_bug.cgi?id=773917
The portable way to have the dashes to be rendered as ASCII minuses is
to use the sequence backslash-dash, use this style at least for text
that can be copied and pasted (e.g. command names, file names, element
options).
Also use backslash-dash in the NAME section as suggested by lexgrog(1).
https://bugzilla.gnome.org/show_bug.cgi?id=773917
Commit 215cfcf993 (gstreamer: Fix memory leaks when context parse
fails) fixes some memory leak, but in one of the newly added calls to
g_clear_error() the wrong variable was passed.
When failing to parse command line options, free the "err" variable, not
the "error" one.
https://bugzilla.gnome.org/show_bug.cgi?id=773907
Introduce a new operator ':' - e.g. element1 ':' element2
For example, 'uridecodebin : encodebin' -
if the encodebin has multiple profiles compatible with the
decodebin, multiple links will be created.
With '!' , after one delayed link is successfully done, the
pad-added callback is disconnected.
https://bugzilla.gnome.org/show_bug.cgi?id=751450
This just confuses people, they look at it and try to call it
directly by name, instead of using the public GstElement API.
It stands to reason that it goes without saying that when an
element provides request pads that they can actually be
requested using the standard API, and there's no point in
printing internal implementation details of the element.
