Re: gtk-list Digest, Vol 80, Issue 12

[Erick Pérez Castellanos <erick red gmail com>]

> 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.

I have to say: I didn't said this because I saw some reason for doing it 
other than the abstract behaviour of filterring things.
So you got your point, maybe there's no use doing it.

> 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.

I might agree with this:

> 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.

But I like this better, this is what I thought, and the reason why I asked 
in first place.

> 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.

I'm not asking for nothing, I was just curious, and wanted to know why this 
was like this.

> ciao,
>  Emmanuele.

Thxs for the explanation. Everything is brighter now.