Re: GTK+ scene graph, API deprecations

[Alexander Larsson <alexl redhat com>]

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.