[gst-devel] locale problems with our registry

[Thomas V. S. <th...@ap...>]

After merging of caps, I had issues with any command I launched; lots of
caps parsing criticals similar to
 ** (process:16464): CRITICAL **: Could not parse caps: 111 video/x-svq,
width=(int)[16,4096], height=(int)[16,4096],
framerate=(double)[0,1,79769e+308], svqversion=(int)1

Ronald pointed me to the fact that the double values contain commas :)

So, I started looking into why this is happening.  The registry is being
saved with caps containing , instead of . for decimal points (I'm in
locale es).

I checked the caps xml saving code, and it relies on g_value_transform. 
The API docs for that say:

Tries to cast the contents of src_value into a type apropriate to store
in dest_value, e.g. to transform a G_TYPE_INT value into a G_TYPE_FLOAT
value. Performing transformations between value types might incour
precision lossage. Especially transformations into strings might reveal
seemingly arbitrary results and shouldn't be relied upon for production
code (such as rcfile value or object property serialization). 

I guess locale issues are one good reason why we shouldn't be using htis
for object property serialization...

Anyone have a suggestion on how to fix this properly ? (ie, NOT by hacks
like "run it in the C locale always")

Personally, I think we shouldn't rely on string serialization for
something like caps; if it's OK for everyone I'd like to forwardport the
code we had to write caps as proper XML.

Thomas

Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
The clock is set for nine but you know you're gonna make it eight
All the people that you've loved they're all bound to leave some
keepsakes
I've been swinging all the time, think it's time I learned your ways
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/