My former email was completely wrong, sorry. Il giorno ven, 19/02/2010 alle 16.46 +0100, Lionel Dricot ha scritto: > > > (simpler approach, but I guess this is visually _very ugly_ > and > counterintuitive for the user). > > In any case, I wouldn't want a row to change its appearance... > > So, what is the best option between the current behaviour and > the "show > all parents" (the first I presented)? I guess there is no > general > answer, but that the current is more intuitive for the > programmer, and > it is easier to workaround it if you need to (I guess that's > what > seahorse does, for instance). > > Still, a convenience method to switch from the current > behaviour to the > "show all parents" one would be a nice feature. > > > > > The more I'm thinking about, the more I'm scratching my head. In fact, > as soon as you are using TreeModel with children, I cannot find any > usecase were filters could be useful in their current shape. > > > Take for example a list of emails nested by convestation (gmail-like). > If you do a search, you don't want a mail to be hidden if it matches > the search but the parent is not. There should be some usecase were > the current behaviour is useful but I fail to find one.
I do see one: you are exposing a filesystem with your treeview, and want to show all folders your applications should process. At a certain moment, a directory is removed from this list (because the app decides so, or the user unselects it someway - but you don't want to remove it from the treeview), so now visible_func returns False for it. In your desired approach, visible_func must change for _all_ children (and grandons and so on). In the current one, only for the removed row. That's why I think there is no obviously "right" approach for every situation. I'd also say that since a tree is usually associated to some hierarchy, the current one totally makes sense, while the email example But that said, what I had totally missed is that while the current behaviour _could_ be obtained (by changing visible_func) if pygtk behaved as you desire, vice-versa your desired behaviour is _not_ obtainable in the current situation (as far as I know, obviously)... > > I've tried to take the problem in every possible way but I don't find > any solution to not hide children with an hidden parent. All the > examples I could find on the web are always for flat list. I suspect > that the documentation is also written with flat lists in mind. > > > > > So, here's my question : how can you use filter with TreeModel if you > are not flat ? Please don't tell me to rewrite my TreeModel. It's > exactly what I wanted to avoid when I started this refactorisation : > use GTK as it should be, separating the model from the view. > That makes totally sense... and after reading your example I took a look at Evolution, and saw it obviously recreates the TreeModel. Pietro _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
