[gst-devel] Re: dparams roadmap (AKA dparams are dead, long live control pads)
ensonic at hora-obscura.de
Tue Mar 1 01:53:04 CET 2005
>On Fri, 25 Feb 2005 14:32:30 +0100, Stefan Kost <ensonic at hora-obscura.de> wrote:
>>another quicky note:
>>How does the application can find out for which gobject properties it makes
>>sense to add an envelop/controller to. If I recall right e.g. sinesource has two
>>properties called sync and buffer-size. It wouldn't make sense to expose them to
>> be controlled.
>>Its bacillay that elemets have static and dynamic properties.
> The trick with this new way of handling, is that it's the
>user/application that chooses which GObject properties it wishes to
>control. The problem with the dparams way of doing things, as you
>pointed out this weekend, is that it exposes some properties twice
>(once through gobject and once through dparams). Here you can control
I very much understand that, but as pointed out there are many cases,
where this is not desirable or even undoable.
At first the GstEnvelope/Control could refuse to control
Further all params that have G_PARAM_CONSTRUCT|G_PARAM_CONSTRUCT_ONLY
set should be skipped.
That would just be sanity checks though.
> So in fact what you want is a way, with the new method, to tell the
>user/application that such property of an element is fit (or not) for
>use with a controller. We need to find a light solution to do that,
>because that means having to implement that too in (eventually) all
>elements. Is there maybe a GObject-generic way of doing that ?
Not that I am aware of a practicable one.
a) One idea I had was implementing the controllable parameters like gtk
does it with the style properties. The nice thing is the separation of
static and synamic properties.
The bad thing about it is - erm the separation again :( (the properties
could not be used with g_object_set/get then).
b.) custom paraspec types - too much work?
c.) custom GParamFlags in the paramspecs? We could define flags outsides
glibs scope (G_PARAM_USER_SHIFT).
downside, this need care to avoid collisions.
d.) an interface - too much work too?
I currently look the the 6 properties of the sine-source and that tells
me, that we really need to disinguish between static and dynamic
(controllable) properties. But it is just that name that can be easilly
The most logical way to me would be c) - although it looks a little
dangerous. What do others think?
More information about the gstreamer-devel