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

[Edward Hervey]

Hi,

On Mon, 28 Feb 2005 10:48:06 +0100, Stefan Kost <ensonic at hora-obscura.de> wrote:
> 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.

  That would already be a good way of "sorting" what properties we can
"enveloppe". But some (enum, flag, strings) properties MIGHT want to
be handled by an enveloppe, so we need to have a way to overrid that
default sanity check.

>
> >  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?

  Agreed on c), it also seems to be the fastest/lightweight way of doing it.

>
> Ciao
>   Stefan
>

  Edward