Re: RFC: Operation Options API proposal



On 25/03/2011 11:33, Iago Toral Quiroga wrote:
>>> > > If we have get/set_* then I think we do not really need a get/set_value
>>> > > and could go with a get/set_data that would receive and return a
>>> > > pointer. BTW, out of curiosity, do we have an example caps that could
>>> > > need this GValue/pointer API?
>> > 
>> > I don't think that any specific cap would need that. My (vague)
>> > understanding is that using GValues may ease the work of binding
>> > writers, but not too sure. Is there a binding writer in the room?
> Well, Simón worked on the GObject introspection support in Grilo, so
> maybe he can shed some light here, Simón?
> 

I think I've just found a big argument for GValue. Remember that idea
about being able to check whether a GrlOptions obeys to a given GrlCaps?
The stuff we initially called grl_caps_fixate_options() or something
like that.
Well, now that I've tried things a bit, I believe that GrlCaps should
not depend on GrlOperationOptions, therefore, I have moved it, and it
becomes:
  grl_operation_options_obey_caps (GrlOperationOptions *options,
      GrlCaps *caps,
      GrlOperationOptions **supported_options,
      GrlOperationOptions **unsupported_options);
That means we need to create new options objects, and copy some of the
values from @options to them.
Yes. We want to copy values. Therefore, we want to store somewhere a way
to copy them (a copy function).
Also, we want a way to destroy them when @options is destroyed. We have
that in GData, but when copying the value, we want to transmit it to the
new options, unfortunately, GData doesn't allow us to get it.

Fortunately, there is a structure in GLib that already handles the copy
and free functions of a value: GValue.

So I feel enclined to use GHashTable + GValue. That's what libsoup does
for instance:
http://git.gnome.org/browse/libsoup/tree/libsoup/soup-value-utils.c

I actually feel inclined to take their code, but I guess I can't since
they seem to be LGPLv2 and we are LGPLv2.1+. Any lawyer here to
confirm/infirm that?

Guij


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]