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
