Re: GTK+ scene graph, API deprecations

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


Alejandro Piñeiro

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