Re: Alternative to swallow GtkContainer into GtkWidget

[Sébastien Wilmet <swilmet gnome org>]

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