On mån, 2014-08-18 at 18:09 +0200, Sébastien Wilmet wrote: > On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote: > > Because every time we try to clean up GtkTreeView, we break some random > > application. It's a widget that has twenty three gazillion use cases, and > > so we have to keep it a mess, because removing the mess means removing one > > use case, and we can't do that. > > So the problem is because GtkTreeView was developed as policy-free as > possible. Now the new widgets are written with more policy, which makes > the API easier to use, with a simpler implementation.
As I see it there are two fundamental problems with GtkTreeView. First of all it has a model-view split, but there is no way to save any state in the view. For example, if the model has a "char *icon_name" column, then every time we draw a row we read the icon name from the column, set it as a property of the (one and only) pixbuf cell renderer, and then ask the cell renderer to draw itself. Now, since the cell renderer has no state it has to start from scratch each time, including reading the icon from *disk*. A few releases ago we added a cache for the icon theme, so we're not quite as bad as this any more, but it still happens if you have more different icons than the size of the cache. This doesn't only affect pixbufs. For instance if you have a tree with a lot of (mostly static) text you want to be able to cache pangolayouts for things like rendering of visible rows. The lack of a calculated state for the view also makes it hard to integrate with CSS for theming, as there is no view tree to do matching against. Secondly, it duplicates the entire size calculation machinery. Since we had no other way to make lists people started using TreeView for a lot of things, including more complex layouts. This lead to things like GtkCellAreaBox which essentially re-creates GtkBox but for cell renderers only. This kind of duplication is wasteful, hard to maintain and hard for users to understand. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
