Re: GTK+ scene graph, API deprecations

["Jasper St. Pierre" <jstpierre mecheye net>]

On Mon, Aug 18, 2014 at 9:50 AM, Sébastien Wilmet <swilmet gnome org> wrote:

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
> > 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.

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.

... ahahahahaha

 

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.

Ah, that's why. I vote you a volunteer for the GSK-ification of GtkTreeView then.

 

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?

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.

You're welcome to try, though.

 

--
Sébastien

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

--
  Jasper