Web lists-archives.com

Re: Alternative to swallow GtkContainer into GtkWidget

On Tue, Aug 02, 2016 at 04:48:03PM -0700, Jasper St. Pierre wrote:
> 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.

You should at least be aware that GtkWidget violates several OOP
best-practices, namely [1] :

1. A class must know what it contains, but it should never know who
contains it.

2. Derived classes must have knowledge of their base class by
definition, but base classes should not know anything about their
derived classes.

3. Classes should not contain more objects than a developer can fit in
his or her short-term memory. A favorite value for this number is six.

Those OOP best-practices are not there just to bother developers,
following them makes a code easier to understand, more maintainable,

But I think you, the GTK+ maintainers, know what you're doing, of


[1] https://www.amazon.com/Object-Oriented-Design-Heuristics-Arthur-Riel/dp/020163385X/
gtk-devel-list mailing list