Use g_object_new() instead which nowadays has a shortcut for the
no-properties check. It still does an extra GType check in the
function guard, but there's a pending patch to remove that
and it's hardly going to be a performance issue in practice,
even less so on a system that's compiled without run-time checks.
Alternative would be to move to the new g_object_new_properties()
with a fallback define for older glib versions, but it makes the
code look more unwieldy and doesn't seem worth it.
Fixes deprecation warnings when building against newer GLib versions.
https://bugzilla.gnome.org/show_bug.cgi?id=780903
This is useful for feature that are produced after probing a specific
node. You want to reload this plugin if the specific node(s) have been
removed, added, or reloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=758080
In plugin is responsible for calculating a hash of the dependencies
in order to determine if the cache should be invalidated or not.
Currently, the hash combining method removes a bit of the original
have before combining with an addition. As we use 32bits for our hash
and shift 1 bit for each file and directory, that resulting hash only
account for the last 32 files. And is more affected by the last file.
Rotating technique (shifting, and adding back the ending bit), can be
use to make the addition non-commutative. In a way that different order
gives different hashes. In this case, I don't preserve this behaviour
because the order in which the files are provided by the OS is
irrelevant.
In most cases, the XOR operation is used to combine hashes. In this
code we use the addition. I decided to preserve the addition because
we make use of non-random hash ((guint) -1) in the algorithm for
matching files that are not really part of the hash (symlinks, special
files). Doing successive XOR on this value, will simply switch from
full ones, to full zero. The XOR used with whitelist has been preserved
as it's based on a fairly randomized hash (g_str_hash).
https://bugzilla.gnome.org/show_bug.cgi?id=758078
When running gst_registry_scan_plugin_file we were losing the
information about the registry being loaded and ended up adding the
plugin to the default registry which was not correct.
https://bugzilla.gnome.org/show_bug.cgi?id=752662
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
Support for (nullable) was added to G-I at the same time as nullable
return values. Previous versions of G-I will not mark return values as
nullable, even when an (allow-none) annotation is present, so it is
not necessary to add (allow-none) annotations for compatibility with
older versions of G-I.
https://bugzilla.gnome.org/show_bug.cgi?id=730957
It's only used internally, most other users will likely
want to use gst_registry_find_plugin() directly instead
(and if not, they can easily walk the list and doing the
strcmp themselves).
This is an implementation detail really, and it's not
clear what anyone would do with this. It's unused as
far as I'm aware, so just remove it for now.
Remove GST_MAJORMINOR and replace it by GST_API_VERSION
Also set GST_VERSION_{MAJOR,MINOR,MICRO,NANO} explicitely
now.
All versions are at 1.0.0 now for the release soon but
API/ABI can still change until the 1.0.0 release.
Next release versions until 1.0.0 will be 0.10.9X and
these will be release candidates. GST_VERSION_* will
nonetheless stay at 1.0.0.0.
This is a string describing a date and/or date/time in a simple subset of
the ISO-8601 format, namely either "YYYY-MM-DD" or "YYYY-MM-DDTHH:MMZ" (with
'T' the date/time separator and the 'Z' indicating UTC).
The main purpose of this field is to keep track of plugin and element versions
on an absolute timeline, so it's possible to determine which one is newer when
comparing two date time numbers. This will allow us to express 'replaces'-type
relationships betweeen plugins and element factories in future, even across
different modules and plugin merges or splits (source module version numbers
aren't particularly useful here, since they can only meaningfully be compared
within the same module). It also allows applications and libraries to reliably
check that a plugin is recent enough without making assumptions about modules
or module versions.
We use a string here to keep things simple and clear, esp. on the build system
side of things.
https://bugzilla.gnome.org/show_bug.cgi?id=623040
