[gst-devel] [gst-cvs] gst-plugins-bad: videosignal: change pattern data type to uint64, add property and message field

René Stadler mail at renestadler.de
Sun Sep 27 11:45:18 CEST 2009

Tim-Philipp Müller schrieb:
> On Sat, 2009-09-26 at 22:54 +0300, Stefan Kost wrote:
>>> videosignal: change pattern data type to uint64, add property and message field
>>> Keeps the old uint typed value support for compatibility.
>> This element is in plugins bad. I think its fine to just break the API. If
>> people use this for real, then they should push that it goes to good :)

Actually, _I'm_ using it for real of course, and this is the best way of 
breaking the chicken-and-egg situation for me :)

> Well, you're right of course, but for elements where we know that people
> are using them already and where it costs us hardly anything to keep
> things backwards compatible, we should do that IMO. We can then remove
> the deprecated API after a while or when the element is moved to -ugly
> or -good.
> And we really shouldn't ever change API in a way that may lead to
> crashes for users of the old API (as changing a property from uint to
> uint64 type without changing the property name might, for example).

Works perfectly here since I believe the property name and message field should 
really keep the *-uint64 name in the long term. There's some gotchas about 
handling 64 bit integers in C, so I like putting a fat reminder about that 
right into the API. Just think g_object_set (queue, "max-level-bytes", 0, 
"max-level-time", 0, NULL), it looks so innocent :)

> Also, if we're not even trying to accommodate existing users of -bad
> elements where it's easy for us to do so, then people will just pressure
> us to move elements into -good prematurely. That's not something I'm
> particularly keen on.
>  Cheers
>   -Tim

   René Stadler

More information about the gstreamer-devel mailing list