When printing a GstStructure property (e.g. the "stats" property in
rtpsession) the first field is printed on the same line of the type
description, and this is both inconsistent compared to how Enum values
are printed and confusing as the reader might miss the first field.
To fix this, add a newline before printing GstStructure fields in
properties.
NOTE: this does not change the existing inconsistent behavior of an
extra newline *after* a GstStructure property, but the latter is not as
annoying and it would take more effort to fix because GstStructure
fields are printed in CAPS descriptions too.
gstharness.c: Use G_GSIZE_FORMAT instead of hard-coding %zu
error: unknown conversion type character 'z' in format [-Werror=format]
gst-inspect.c: GPid is void* on non-UNIX, and we only use it on UNIX
error: initialization makes pointer from integer without a cast [-Werror]
gstmeta.c: Use and then discard value
error: value computed is not used [-Werror=unused-value]
With this, gstreamer builds with -Werror on MinGW
Commit 56b4fbef5e refactored the pipe code
to use GLib utility, but the patch was hading some other changed. LESS
env was now hardcoded in the middle instead of from a define and was
changed from FXR to -RX. The "-" is not even valid for LESS env, and
with the lost of F, we would still use a pager when the content fits the
terminal.
Setup it only if we have something to print out about inspected results.
Otherwise, gst_tools_print_version() output will be redirected to pager and also
exit immediately without waiting child process.
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.
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.
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753851
Don't print all the different pad functions, it's just
confusing and no one has ever needed to know this for
anything ever anyway, it's just useless information.
Besides, we also label the default implementations as
'custom' implementations (the code that tries to
prevent that doesn't actually work it seems).
https://bugzilla.gnome.org/show_bug.cgi?id=736377