Re: Alternative to swallow GtkContainer into GtkWidget

["Jasper St. Pierre" <jstpierre mecheye net>]

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 <swilmet 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