Re: Alternative to swallow GtkContainer into GtkWidget

[Sébastien Wilmet]

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,
etc.

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

--
Sébastien

[1] 
https://www.amazon.com/Object-Oriented-Design-Heuristics-Arthur-Riel/dp/020163385X/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Alternative to swallow GtkContainer into GtkWidget

[Jasper St. Pierre]

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

Re: Alternative to swallow GtkContainer into GtkWidget

[Sébastien Wilmet]

On Tue, Aug 02, 2016 at 07:57:04PM +0200, Sébastien Wilmet wrote:
> I see at:
> https://wiki.gnome.org/Hackfests/GTK2016/Day1
> 
> That there is maybe a plan to merge GtkContainer into GtkWidget.

More precisely, "Next step after that would be to make gadgets real
widgets and add them to their parent widget directly."

So the goal is: gadget == GtkWidget. Why would it be wrong to have
gadget == GtkContainer? I suppose that the problem at the source is this
one: how to implement a GtkWidget that (1) composes several other
widgets and (2) is a direct subclass of GtkWidget, to not expose that
the widget is implemented internally with a GtkGrid, for example.

If my supposition is correct, there is a clearer solution: have a
protected function gtk_widget_set_delegate (GtkWidget *delegate);
If priv->delegate != NULL, GtkWidget would delegate everything to
priv->delegate. A way to achieve this is with a macro like:

GET_PRIV(widget) (widget->priv->delegate != NULL
  ? widget->priv->delegate->priv : widget->priv)

So each time the widget accesses one of its instance variables, it
accesses the instance variable of the delegated widget if non NULL.

That way, it would be possible to use e.g. GtkGrid internally, without
exposing to the user which container is used (it's an implementation
detail).

And the various utility classes (gadgets) could be composed exactly how
we add e.g. a GtkScrolledWindow.

Or do I have a wrong idea of what would be a "gadget == GtkWidget"?

PS: sorry for my ramblings, but out of curiosity, I'm interested to know
more details about that gadgets plans.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list