hi; On 16 August 2014 16:23, Sébastien Wilmet <[email protected]> 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] _______________________________________________ gtk-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-devel-list
