Re: GtkRecentFilter and GtkFileFilter

[Emmanuele Bassi <ebassi gmail com>]

On Mon, 2010-12-13 at 02:26 -0300, Erick Pérez Castellanos wrote:

> > > I was using GtkRecentChooser interface a little a few days ago and I 
> > > realize
> > > you can add filters to the list of recent files and realize the
> > > GtkRecentFilter class could easily inherit from GtkFileFilter
> > > Why is this not like this ?
> >
> > because the filtering machinery is not available to FileFilter
> > sub-classes, and it would have to be re-implemented anyway.
> 
> I don't understand what you mean with this. 

FileFilter is an opaque object: the instance and class structures are
not public, hence nobody can actually sub-class this type.

though this can be circumvented (at least with some hackery), this would
provide an obstacle when it comes to implementing sub-classes that add
new filter rules and expect them to run along with the ones provided by
the super-class - i.e. I could not simply add a rule to filter recently
used resources described by a GtkRecentInfo to the other rules present
in FileFilter.

one way to fix this would be to make the GtkFileFilter class public,
move the filter function implementation inside an overridable virtual
function, and allow sub-classing.

it could be doable for gtk3, and it would be a minor API deprecation.

the real question is, though, what would happen if I used a sub-class
like GtkRecentFilter inside a GtkFileChooser; obviously it should work,
but it wouldn't make much sense.

+++

sub-classing is not always the good design practice; in this case, the
FileChooser and RecentChooser interfaces delegate the filtering
functionality to a separate class; since a FileChooser and a
RecentChooser have no direct relationship sub-classing their filters
might not be a good idea.

something that could be done if we really wanted a flexible *Chooser
filter would be redesigning the Filter object into a more generic class,
e.g. a GtkResourceFilter, which can filter using a regular expression
(instead of a pattern), a content-type from GIO and maybe a URI scheme;
it would need to be public to allow sub-classes to chain their own
behavior on top of the base one, this way it could be used for all the
*Chooser implementations - including the GtkAppChooser widget that
recently landed in master.

obviously, we're late for gtk+ 3.0 for such a re-design, but I'm pretty
positive that this could be implemented in a backward compatible way for
gtk+ 3.2.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi