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