On Mon, Aug 18, 2014 at 9:50 AM, Sébastien Wilmet <swil...@gnome.org> wrote:
> 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. ... 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
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
