There isn't really any need to provide public API for that. It's not
used anywhere in practice, and we aim to provide an API that works
for GstCaps, not some kind of generic set manipulation API based on
GValue. Making this private also makes it easier to optimise this
later. We can always put it back if someone actually needs it.
We introduced our own when GLib didn't want to add a GType
for GError. But now that there is one, we can use GLib's
unconditionally and remove our version.
Make the memory object simply manage the data pointer and the maxsize and move
the offset and size handling to common functionality.
Use the READONLY flag to set a readonly lock.
Remove the data and size fields from the unmap method. We need an explicit
resize operation instead of using the unmap function.
Make internal helper lock and unlock functions.
Update unit test and users of the old API.
Which we had to add because GLib didn't have it
back in the day. Port everything to plain old
G_TYPE_DATE, which is also a boxed type. Ideally
we'd just use GDateTime for everything, but it
doesn't support not setting some of the fields
unfortuntely (which would be very useful for
tag handling in general, if we could express
2012-01 for example).
https://bugzilla.gnome.org/show_bug.cgi?id=666351
There are many good use cases for GstIndex and we want
to add it back again in some form, but possibly not with
the current API, which is very powerful (maybe too powerful),
but also a bit confusing. At the very least we'd need to
make the API bindings-friendly.
Add a GstControlBinding class. This is a preparation for making the
controlsources generate double valued control curves and do the gparamspec
mapping in the control binding. Now the API in GstObject is again mostly
for convenience.
An extra application preset dir help to organize presets created for special
purposes. Fixes#660760
API: gst_preset_set_app_dir(), gst_preset_get_app_dir()
Add _full variants of the pad function setters that take a destroy notify.
Make some macros that make the old method name pass NULL to this new
function.
Add the pad mode to the activate function so that we can reuse the same function
for all activation modes. This makes the core logic smaller and allows for some
elements to make their activation code easier. It would allow us to add more
scheduling modes later without having to add more activate functions.
Remove the getcaps function on the pad and use the CAPS query for
the same effect.
Add PROXY_CAPS to the pad flags. This instructs the default caps event and query
handlers to pass on the CAPS related queries and events. This simplifies a lot
of elements that passtrough caps negotiation.
Make two utility functions to proxy caps queries and aggregate the result. Needs
to use the pad forward function instead later.
Make the _query_peer_ utility functions use the gst_pad_peer_query() function to
make sure the probes are emited properly.
Make that implizit with attaching/detaching controlsources. This is a lot easier
and has less invalid state (controlled property without control source).
No one but filesrc used that API. Should probably be replaced by
requiring an "uri" property instead, and then objects can do a
notify on that. Also removed interface structure padding, it's
not needed.
This make the controller even more lightweight (no extra object, no extra lock,
less indirections). For object that don't use the controller the only 'overhead'
is a 3 unused fields in the gst_object structure.
The fixate caps function was not used externally and we have vmethods in the
base classes where it is needed.
Update some docs.
simplify some fixate functions in the base classes. Also pass the untruncated
caps to the vmethod.
Better now than later in the cycle. These might come in handy:
sed -i -e 's/GstProbeReturn/GstPadProbeReturn/g' `git grep GstProbeReturn | sed -e 's/:.*//' | sort -u`
sed -i -e 's/GST_PROBE_/GST_PAD_PROBE_/g' `git grep GST_PROBE_ | sed -e 's/:.*//' | sort -u`
sed -i -e 's/GstProbeType/GstPadProbeType/g' `git grep GstProbeType | sed -e 's/:.*//' | sort -u`
No one uses this or should ever need to use it, since
the size is architecture-specific anyway. If normal
integers don't do, one should use 64-bit integers.
