[gst-devel] Re: dparams roadmap (AKA dparams are dead, long live control pads)

[Stefan Kost]

Hi Edward,

>On Fri, 25 Feb 2005 14:32:30 +0100, Stefan Kost <ensonic at hora-obscura.de> wrote:
>  
>
>>Hi Edward,
>>
>>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
>ANY properties.
>
>  
>
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 
g_param_spec_{object|pointer|string|flags}.
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 
avoided.
The most logical way to me would be c) - although it looks a little 
dangerous. What do others think?

Ciao
  Stefan