Alternative to swallow GtkContainer into GtkWidget

[Sébastien Wilmet <swilmet gnome org>]

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