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 694851 - Make Gtk.Widget.freeze_child_notify a context manager
Make Gtk.Widget.freeze_child_notify a context manager
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: introspection
Git master
Other Linux
: Low enhancement
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2013-02-28 10:58 UTC by Jonathan Ballet
Modified: 2018-01-10 20:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonathan Ballet 2013-02-28 10:58:25 UTC
Gtk.Widget.freeze_notify() is a context manager, Gtk.Widget.freeze_child_notify() should have the same behavior.
Comment 1 Jonathan Ballet 2014-09-15 09:35:14 UTC
I'm trying to produce a basic test case, without the context manager, but I have troubles producing something which works.

I have the following, which I expected to pass:


    child_signals = []
    def child_notify_handler(widget, prop):
        child_signals.append((widget, prop.name))

    widget = Gtk.Button()
    container = Gtk.Box()
    container.add(widget)

    widget.connect("child-notify", child_notify_handler)

    container.freeze_child_notify()
    container.child_notify(widget, "expand")
    self.assertEqual([], child_signals)
    container.thaw_child_notify()

    self.assertEqual(1, len(child_signals))
    self.assertEqual((widget, "expand"), child_signals[0])

... but it fails on the second `assertEqual` because `container.child_notify()` actually calls the `child-notify` handler, which I thought it wasn't supposed to do since I froze these signals just before.

What am I doing wrong here?
Comment 2 Simon Feltman 2014-09-18 01:13:34 UTC
(In reply to comment #1)
> ... but it fails on the second `assertEqual` because `container.child_notify()`
> actually calls the `child-notify` handler, which I thought it wasn't supposed
> to do since I froze these signals just before.
> 
> What am I doing wrong here?

The GTK+ code is extremely confusing, at one point this probably used to work, but looking at [1], a new method gtk_container_child_notify() was added which masks gtk_widget_child_notify() and queues the notification on the child not the container. See also [2]

You might try using Gtk.Widget.child_notify(container, widget, ...) or setting child property with container.child_set_property() for the test.

[1] https://git.gnome.org/browse/gtk+/commit/?id=deb271d355
[2] https://git.gnome.org/browse/gtk+/tree/gtk/gtkcontainer.c?id=3.13.9#n830
Comment 3 Jonathan Ballet 2014-09-21 17:21:58 UTC
Hum, I'm still trying to understand what's happening, but I'm overly confused.

I tried the following:

* using `container.child_set_property(widget, "expand", True)` instead of calling directly `container.child_notify(...)`. This still triggers the `child-notify` event, although it's supposed to be frozen. Moreover, this single call actually triggers the event 3 times (with the other "child properties" such as `padding`, `fill` and finally `expand`).

* I can't call `Gtk.Widget.child_notify(container, widget, ...)` for some, it still expects 2 arguments (a widget and a string apparently).

I'm trying to understand what's happening in the C code, but that's confusing.
Comment 4 GNOME Infrastructure Team 2018-01-10 20:22:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pygobject/issues/45.