Re: Operation options (filtering, sorting and more)

[Guillaume Emont <gemont igalia com>]

On 15/03/2011 18:06, Juan A. Suárez Romero wrote:
> On Tue, 2011-03-15 at 17:48 +0100, Guillaume Emont wrote:
>>> That is, for instance, having a GrlOptionsSort object/structure with
>> the
>>> api related to do sorting, and having GrlOptionsFilter with the api
>> to
>>> handle filtering.
>> I fear that solution could make things even more complicated than the
>> problem it's trying to solve. 
> 
> I fail to see why having things separated can complicate the problem.
Depends what you call separated. The things that Ifear would complicate
the issue are:
 - having more than one option structure passed to the media source
operation function (_search()/_browse()/...)
 - having unneeded inheritance.
I wouldn't be against something like:
typedef struct {
  GrlFilter *filter;
  GrlSortParameters *sort_params;
} _GrlOperationOptionsPriv;

void grl_operation_options_set_filter (GrlFilter *filter);
void grl_operation_options_set_sort_parameters (GrlFilter *filter);

But I am not sure it is really needed, and it would need slightly more
work on the caller side.

> From a user pov, I see it easier to have things separated: user can
> focus in sorting or filtering, each of them with its own api, instead of
> a big blog with lot of api there.
> 
I don't think having a lot of setter-like methods on that structure is a
big issue, as long as it can be made obvious from their name what they
do (_add_key_filter(key, value), _set_key_sort (key, sort_order))

> In some way, i feel weird mixing all options in the same place, but then
> having one type for options and another type for capabilities...
Well, one argument I have to separate them is that in your filtering
branch, there are a lot of functions starting with grl_filter_caps_,
which makes me think things could be clearer if we had a GrlFilterCaps
type...

Guij
> 
> 	J.A.
> 
> 
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list
>