Re: RFC: Operation Options API proposal
- From: Guillaume Emont <gemont igalia com>
- To: grilo-list gnome org
- Subject: Re: RFC: Operation Options API proposal
- Date: Fri, 25 Mar 2011 13:04:10 +0100
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]