After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 730974 - Auto bind template children in gtk_widget_get_template_child()
Auto bind template children in gtk_widget_get_template_child()
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Class: GtkBuilder
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GtkBuilder maintainers
GtkBuilder maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-30 02:13 UTC by Simon Feltman
Modified: 2014-05-30 19:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Simon Feltman 2014-05-30 02:13:26 UTC 
This would help supporting Composite Templates in high-level bindings because it allows avoidance of gtk_widget_class_bind_template_child_full() in the GObject class initializer. It seems this is just a matter of changing the boolean flag in the call to get_auto_child_hash():

https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?id=3.13.2#n16856

If this is not acceptable, one alternative is to give access to the builder object used by the template, something like gtk_widget_get_template_builder()

From this we can use the builder to access template via. an override of get_template_children():

builder = widget.get_template_builder()
child = builder.get_object('some_child')

See also bug 701843
Comment 1 Tristan Van Berkom 2014-05-30 15:01:17 UTC 
Hi Simon,

It is not possible to implement gtk_widget_get_template_child() in this way because there is no GtkBuilder that exists at any time that a GtkWidget subclass could ever call gtk_widget_get_template_child(), and this should not really change (the GtkBuilder instance only exists for a quick moment inside the scope of gtk_widget_init_template(), aside from this there is no need for an entire instance of GtkBuilder to exist).

By the way I have been watching the pygobject bug and I'm happy/excited to see progress in this front. Is calling gtk_widget_class_bind_template_child_full() from subclassed python widget's class initializers really a show stopper for you ?
Comment 2 Simon Feltman 2014-05-30 19:34:54 UTC 
(In reply to comment #1)
> ... (the GtkBuilder instance only exists for a quick moment inside
> the scope of gtk_widget_init_template(), aside from this there is no need for
> an entire instance of GtkBuilder to exist).

Ok, thanks for the explanation.

> Is calling gtk_widget_class_bind_template_child_full()
> from subclassed python widget's class initializers really a show stopper for
> you ?

Nope, not a show stopper. Just a little inconvenience. We can work around it by adding our own recursive widget search and caching hack, or by doing things properly and calling gtk_widget_class_bind_template_child_full() based on a Python descriptor developers add to their class.