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

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.


Thxs for the explanation. Everything is brighter now.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]