Re: GTK+ scene graph, API deprecations

[Piñeiro <apinheiro igalia com>]

On 08/19/2014 03:24 PM, Alexander Larsson wrote:
> 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.

This also affects the accessibility support, as at any point, the
accessibility technologies would want to get info (text, status, etc)
from a given cell. This leads to custom cell objects (in theory
fly-weight objects) that maintain accessibility-related caches. And the
accessibility implementation of GtkTreeView is also really complex and
regression-prone.

BR

-- 
----
Alejandro Piñeiro