Re: Operation options (filtering, sorting and more)

[Guillaume Emont <gemont igalia com>]

On 15/03/2011 19:03, Juan A. Suárez Romero wrote:
> On Tue, 2011-03-15 at 18:46 +0100, Guillaume Emont wrote:
>>> 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()/...)
> 
> I never said you need to pass more than one structure to operations: all
> allowed options (filtering, sorting) will be encapsulated in one
> GrlOptions.
> 
>>  - having unneeded inheritance.
> 
> Fair enough. Don't use it if it is not needed.
> 
>> 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. 
> 
> 
> What I mean is having a GrlFilter and related operations for filtering;
> GrlSort and related operations for sort.
> 
> And have one api to add GrlFilter and GrlSort in a GrlOptions that would
> be passed to the plugin. The same to recover them.
Is that different to the small example I gave above? Granted, the
parameter to _set_sort_parameters() is wrong, and I didn't list
accessors, but they were implied.
> 
> For me it is cleaner.
Hmm, dunno.
I think I will write a new version of the "big debate" document
tomorrow, to make things clearer in my mind, and hopefully for everybody
else as well.

Guij