Re: GTK+ scene graph, API deprecations

On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
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

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.

Ok I see.

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.

But GtkTreeView has the advantage that it already works and is mostly
feature complete (to display trees too), and is used in lots of
libraries and applications, with custom models etc. It seems easier to
me to do code refactorings in GtkTreeView than creating a completely new
widget from scratch. And if GSK can potentially simplify a lot the
GtkTreeView implementation in the future, and with the API break for GTK
+ 4, another solution is to simplify both the API and implementation of
GtkTreeView for GTK+ 4.

That said, I've never worked on the GtkTreeView code. Maybe one of the
reasons to create a new widget from scratch is because nobody wants to
work on GtkTreeView anymore. But if that is the case, maybe in 10 years
nobody will want to work on GtkListBox anymore, and developers will
reinvent the wheels continually, by deprecating more and more APIs,
creating new ones every decade, and make application developers grumpy.

So in short, if some of the GTK+ code is a mess, why not keeping the
same APIs while improving internally the code?


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