Re: GTK+ scene graph

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 16 August 2014 16:23, Sébastien Wilmet <swilmet gnome org> wrote:

> With GskLayerContent, will it be possible to unify cell renderer and
> widget drawing models? To simplify significantly the GtkTreeView
> implementation, for example, and be able to insert a GtkWidget in a
> GtkTreeView.

not without breaking API.

we cannot really re-implement GtkWidget using GSK layers without
breaking ABI in any case — think of whoever connects to
GtkDrawingArea's ::draw signal, or whoever subclasses a GtkWidget and
overrides the draw() virtual function; suddenly, they wouldn't be
drawing on a cairo_t associated with a whole GtkWidget, but on a GSK
layer's content. where would that layer go? on top? at the bottom of
the stack? what happens if I connect to ::draw and then stop the
signal emission?

for GTK+ 3.x, the scene graph API is going to be available for you to
write new widgets with a scene inside them, and to put widgets inside
a scene. the short term goal is to fully replace the current usage of
Clutter and Clutter-GTK (and possibly Clutter-GStreamer) throughout
the GNOME stack; anything else is on a purely speculative basis, and
it will land if and only if it does not break API and/or ABI. a full
rework of the GTK widgets to use the scene graph API is going to wait
until we can release GTK+ 4.

it is also my opinion that, if we break API, we may as well deprecate
GtkTreeView and replace it with the list widget backend by a model,
and drop the whole cell renderer scene API in the first place.

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[ ] ebassi [ gmail com]