[gst-devel] State of DParams

[David Schleef]

On Tue, Dec 21, 2004 at 12:53:46PM +0100, Stefan Kost wrote:
> one more comment. If your approach turns normal GObject properties into DParams,
> how does an element controls the changing policy. Imaging an element having a
> quality switch and a few other properties. The quality can't be changed when in
> playing mode (as e.g. this would need to reconfigure some lookup-tables).
> Suggestions:
> a.) elements just ignore such changes when they happen, and only evalue the
> property value when going to play-state next time
> b.) we add an interface to publish such policies

When a property is 'taken over' by a DParam, it makes sense to just
ignore any changes attempted by set_property().

My two cents:  In the ideal case, I'd like to see dparams seamlessly
add a request pad to the element, and when the pad is connected, pull
control information from the pad, else use the property information.
I'm indifferent to having a third state which uses automatic
generators/interpolaters (like the existing DParams), although this
might be a good compromise if the core isn't up to handling *lots*
of control information being passed around.



dave...