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. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
