Re: RFC: Operation Options API proposal



On 25/03/2011 12:47, Iago Toral Quiroga wrote:
> El vie, 25-03-2011 a las 12:18 +0100, Guillaume Emont escribió:
> (...)
>>> What about a more complex filter like the ones I put as examples in some
>>> other e-mail I sent to the list? Like these:
>>>
>>> A filter with an argument, like:
>>> Artist=X
>>>
>>> A chained filter like:
>>> Artist=X AND Album=Y
>>>
>>> A ranged filter, like:
>>> X < Date < Y
>> I would see something like:
>>  - caps store a list of arguments (or maybe a hashtable), as it would
>> store any other value, on which we can filter, maybe with restrictions
>> on them (can only be equal, or can only compare in a given direction,
>> something like that)
>>  - grl_operation_options_set_filter() (or _add_filter()) checks that the
>> given filter obeys to caps (if non NULL), so does grl_caps_fixate_options().
> 
> What arguments would set_filter() take?
I don't know. But it could be anything the filter designer wants (Juan?
reading this?).
> 
>> Thinking of this, we want to write these checks in only one place. Since
>> we need them both in caps and options, I think they belong to caps. So I
>> think that over the stuff previously listed, we should add:
>>   gboolean grl_caps_can_set_option (GrlCaps *caps, const gchar *key,
>> GValue *value);
>> And probably some helpers (_boolean, _int, _float and _string versions
>> at least).
> 
> So caps_set_option would check that key/value are supported in caps? In
> that case should it not be named 'caps_test_option' instead?
The name I proposed was caps_*can*_set_option, not caps_set_option. And
yes, caps_test_option is indeed a better name, thanks for providing it.

> Or maybe I
> am not understanding its purpose well.... Also, what is 'key' and what
> is 'value' in the case of a filter with no arguments? (Like the filter
> by types you considered originally)?
could be something like:
  grl_caps_test_option_int (caps, "type-filter", GRL_FILTER_TYPE_VIDEO);
(or would we need a test_option_enum?)

> 
> And another question, how would the options get a reference to the caps?
> 
Two possible models (I plan to implement both):
 - the GrlOperationOptions instance is created with a GrlCaps instance
as parameter
 - the GrlCaps passed to the constructor is NULL, no checks are made
when calling _set_value(), the programmer should call
grl_caps_fixate_options() before launching the operation if they want to
know the options that will be honoured
.
>> Also, maybe Juan can tell us whether the above model fits his ideas for
>> filtering.
> 
> Yes, please :)
> 
> Iago
> 
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list



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