What you miss is that GtkWidget already has container-like behaviors with gtk_widget_set_parent. In fact, the whole API has been awkward. GtkWidgets themselves can have children. GtkContainer is a "convention" interface for a way of manipulating an object that can have children. Not every widget that has children has to implement GtkContainer (though there *are* some features that won't work automatically, like drawing of children, since gtkwidget.c often has checks for GTK_IS_CONTAINER).
It makes sense to me to merge these two APIs so we don't have this impedance mismatch. On Tue, Aug 2, 2016 at 10:57 AM, Sébastien Wilmet <swil...@gnome.org> wrote: > Hi, > > I see at: > https://wiki.gnome.org/Hackfests/GTK2016/Day1 > > That there is maybe a plan to merge GtkContainer into GtkWidget. > > From a software engineering point of view, this looks like a bit scary > to me. > > $ wc -l gtkwidget.c > 17510 gtkwidget.c > $ wc -l gtkcontainer.c > 3880 gtkcontainer.c > > GtkWidget can already be considered a God Class. > > GTK+ is not without bugs. It is already a challenge to maintain a good > stability for a project as big as GTK+. So IMHO the trend should be to > extract some code into new, smaller classes. When there are too many > instance variables, it is more complicated to work on the code and > ensure that what we change is correct. With small classes, we can be > more confident that the code is correct. > > But I think you know well all of this. > > So, instead of inheritance, the alternative is of course composition. A > GtkWidget could use internally a reference to a GtkContainer-like > utility object. And the real GtkContainer subclass could use the same > utility class internally. But using the GtkContainer utility by > composition would require a fair amount of boilerplate, when overriding > the GtkWidget vfuncs. But I'm sure there is a solution to have less > boilerplace. E.g. another utility class that is setup in class_init() > that handles the proxy to the internal container object. > > Just my 2 cents, maybe it's a crack idea. But at least I've shared my > thoughts. I think it's possible to split out more classes, writing more > utilities to share code between widgets, and being able to implement new > widgets more easily. GtkEventController is a good example. > > -- > 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
