17:18 < ensonic> __tim: regarding: g_value_transform, the docs in glib say it should *not* be used for object property 
                 serialisation
17:18 < __tim> ah, right
17:18 < ensonic> __tim: it does not guarrantee that it does its job without loss of preccision
17:18 < wtay> ensonic, we use the gstreamer transforms for caps
17:18 < __tim> well, that's why we have gst_value_* 
17:19 < ensonic> I use g_ascii_strtod / g_ascii_dtostr for that reason
17:20 < wtay> gst_value_serialize/gst_value_deserialize
17:20 < ensonic> __tim: there is no gst_value_transform
17:20 < ensonic> ahh, lemme check
17:20 < __tim> what wtay said (and I wrote in the bug)
17:20 < MikeS> right, but we have a serialisation/deserialisation system; it's used extensively for lots of things
17:20 < __tim> we should fix that if there are problems with floats
17:21 < ensonic> that looks good indeed, I change over to it
17:21 < ensonic> __tim: totally agree, no discussion on that
17:21 < wtay> gst_value_serialize_double also uses g_ascii_dtostr
17:21 < __tim> great :)
17:23 < ensonic> two things: 1.) I really want to move GST_PARAM_CONTROLABLE to gstobject.h, ok?, 2.) What about 
                 GST_PARAM_EDITABLE (better names welcome). it would declar properties as user-editable, but not over time
17:23 < __tim> ensonic: as for the writing todo item, couldn't you just serialize into memory (using GString or so) and then 
               use g_file_set_contents()? These files are fairly small, aren't they?
17:24 < ensonic> __tim: yep, thats probably faster, but letme lookat GKeyFile too
17:24 < wtay> ensonic, I'm all for moving them
17:25 < wtay> ensonic, we also have gstparamspecs.h
17:25 < MikeS> ensonic: EDITABLE sounds like a bad name (I would assume all writable properties are editable)
17:25 < ensonic> wtay: would you also agree with GST_PARAM_EDITABLE?
17:25 < __tim> I thought maybe something clever could be done with GstStructure, like  bling=preset, attack=(double)0.1, 
               foobar=(int)5 etc., but maybe that's just weird, dunno :)
17:25 < MikeS> (I'm not against the idea; I just think the name there is bad. I don't have a better suggestion yet, though)
17:25 < ensonic> MikeS: the idea is editable for users/ui, something that affect processing/quality but does not break internals
17:26 < ensonic> MikeS: but yes, the name is bad :)
17:26 < wtay> I don't have a better name either
17:26 < wtay> this is only to give UI hints?
17:27 < MikeS> USER_EDITABLE ?
17:27 < __tim> GST_PARAM_UI_HINT
17:27 < ensonic> __tim: not sure, but it might push structure quite heavily, but with substructures it might be doable 
17:27 < wtay> __tim, I don't see a need to involve GstStructure in this
17:27 < __tim> ensonic: well, you know more about the details and likely use cases, if it takes 500 lines of code to parse and 
               process the structure, it's probably not smart either :)
17:27 < __tim> ok, was just a brainfart
17:28 < ensonic> __tim: GST_PARAM_CONTROLABLE is also a ui hint already (and it hints that a property make sense to be changed 
                 over time), I was looking for a name that says "this is editable too, but please just once for the pipeline 
                 run)
17:28 < wtay> ensonic, really?
17:29 < MikeS> Mostly-unrelated thought I was having earlier today: it'd be nice for users to set "default properties" via some 
               preset-like mechanism. e.g. have some config file somewhere that said "apply preset foo to all elements of type 
               bar", so you could globally set preferences for some things.
17:30 < __tim> we should just use the GtkRc file parser ;-)
17:30 < ensonic> wtay: the flags should go to gstobject.h as I want to adjust/define GST_OBJECT_PARAM_SHIFT
17:31 < ensonic> MikeS: having a default preset cached in the registry
17:31 < wtay> ensonic, sure
17:32 < MikeS> ensonic: right, but not in the registry
17:32 < MikeS> (the registry is a cache only; I want a separate config mechanism for persistent user configuration. This is also where 
               we should put things like rank-overriding, perhaps?)
17:33 < ensonic> MikeS: yep, the rank thing would be nice too
17:34 < __tim> ensonic: what was wrong with the PARAM_PRESET suggestions again?
17:34 < MikeS> or PRESETTABLE?
17:35 < ensonic> __tim: I would do #define GST_PARAM_PRESETABLE (GST_PARAM_CONTROLABLE|GST_PARAM_EDITABLE)
17:35 < wtay> MikeS, default presets would be easier if the presets were split up like my suggestion in Comment #44
17:35 < __tim> ensonic: why bring the controllable stuff into this?
17:35 < wtay> but controllable just means that it will work with GstController, no?
17:36 < wtay> what does it have to do with presets?
17:36 < MikeS> wtay: point me at the bug we're discussing so I can read #44?
17:36 < wtay> MikeS, #396779
17:37 < MikeS> kthx
17:37 < wtay> MikeS, it might be overkill
17:41 < ensonic> wtay: __tim: nope, controllable just means, it makes sense to control the property over time, gstcontroller can do 
                 that 8for programmed changes), but one can also do a ui with a bunch of sliders (for realtime changes)
17:43 < wtay> ensonic, sure, but you can do that on any ui editable property, even one without the controllable flag
17:45 < ensonic> wtay: thats right, so whats the favourite suggestion then GST_PARAM_USER_EDITABLE, GST_PARAM_PRESET{ABLE}, 
                 GST_PARAM_UI_HINT
17:46 < wtay> UI_HINT sounds silly. EDITABLE too vague
17:47 < wtay> ah USER_EDITABLE
17:47  * __tim is confused - are we talking about a #define (A|B) now or what? why not just  CONTROLLABLE as it is and PRESETTABLE and 
          that's that?
17:47 < wtay> I'm not talking about a define
17:48 < wtay> I'm trying to figure out what you want to use the properties for
17:48 < wtay> 1) CONTROLLABLE = something changable with GstController
17:49 < wtay> 2) USER_EDITABLE = something intented to be changed by a gui
17:49 < wtay> 3) PRESTTABLE = something intended to be saved as a preset
17:50 < wtay> there is much overlap in those use cases
17:50 < MikeS> wtay: Can we think of anything in (2) that is not also in (3)? Anything in (1) not also in (2) and (3)?
17:51 < wtay> 2) the name, you want to change it in the gui but not as a preset or controllable
17:51 < ensonic> imho 3 == 1|2
17:51 < wtay> ensonic, the name property voids that assumption
17:51 < ensonic> wtay: gobject::name should be internal and not on the ui
17:51 < slomo> ensonic: not really imho... 3 == 2 maybe...
17:52 < ensonic> yep, 3 == 2, then 1 is a subset of 2
17:52 < wtay> why is 3 == 2, clearly ::name is not
17:53 < slomo> ensonic: no, there are properties that can be changed by the user and are not controllable (think of encoder settings 
               for example)
17:53 < ensonic> slomo: yes, thats what I meant with subset, some are controlable and some are not bu still editable
17:54 < slomo> ah, yes... sorry
17:54 < ensonic> wtay: is it save to let users change objects names? they have to be kept unique and maybe the app uses them internally
17:55 < wtay> in gsteditor it's improtant to set the name so that the app can get the object
17:55 < ensonic> I think that everything you can configure from the ui, would be candidate for a preset
17:55 < wtay> except for ::name
17:55 < ensonic> wtay: I see
17:56 < wtay> maybe you just want to exclude this special case with a flag
17:56 < ensonic> bah, even simple things can turn ot difficult ...
17:58 < ensonic> yes, I mean I can have an exception in preset to just skip GObject:name even though it has USER_EDITABLE
17:58 < ensonic> wtay: ah, you mean have 3 flags, but have one inverted
17:59 < wtay> or maybe you just want to make it even easier, like have all properties be user-editable except for those marked as 
              NO_USER_EDITABLE
17:59 < wtay> or EXCLUDE_UI
17:59 < wtay> you also don't want to add flags to all existing elements
18:01 < ensonic> hej, I need to run for the bus, thanks everyone for the discussion, I'll make a patch for it and we can check when 
                 the core is open again, if everyone is still happy with it :)
                 
