On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote: > On 16 August 2014 16:23, Sébastien Wilmet <swil...@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. 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? -- Sébastien _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
