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 693618 - set_properties() on Gtk.Widget doesn't work
set_properties() on Gtk.Widget doesn't work
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
Git master
Other Linux
: Normal major
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2013-02-11 20:08 UTC by Jonathan Ballet
Modified: 2013-02-13 08:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch with fix + test for the problems related in this bug report (2.21 KB, patch)
2013-02-11 20:08 UTC, Jonathan Ballet
reviewed Details | Review
Correctly set properties on object with statically defined properties (2.45 KB, patch)
2013-02-12 22:06 UTC, Jonathan Ballet
none Details | Review
Correctly set properties on object with statically defined properties (2.41 KB, patch)
2013-02-12 22:13 UTC, Jonathan Ballet
committed Details | Review

Description Jonathan Ballet 2013-02-11 20:08:15 UTC
Created attachment 235741 [details] [review]
Patch with fix + test for the problems related in this bug report

Calling `.set_properties()` on a Gtk.Widget currently fails with the following message:

  SystemError: error return without exception set

I bissected the faulty commit to http://git.gnome.org/browse/pygobject/commit/?id=fd32acdd97f49f086a8ad5cf2b65862c4e6ccc44

While fixing the problem, I noticed that calling the method with several properties to set would only set one of the property.

The first problem is due to the fact that `result` is not always set to Py_None upon completion (if pygi_set_property_value() returns 0 straight away, it jumps to exit: and returns NULL).
The second problem is related: it exits the while loop as soon as a property has been set by pygi_set_property_value().

Strangely, the test in test_gi.TestPropertyObject.test_multi doesn't show this problem, and I couldn't reproduce it using GObject.GObject directly. That's why I'm reporting against Gtk.Widget.

I made a patch to fix both problem, with one test showing the expected, correct result.

Thanks,

 Jonathan
Comment 1 Simon Feltman 2013-02-12 21:23:50 UTC
Review of attachment 235741 [details] [review]:

Thanks for this! a few comments.

::: gi/_gobject/pygobject.c
@@ +1457,3 @@
+        if (ret != 0) {
+            if (PyErr_Occurred())
+                goto exit;

This seems right. It would be helpful if there was a comment stating that non-zero can mean an error occurred or the property was not found (in which case we try the default set_property_from_pspec).

::: tests/test_overrides_gtk.py
@@ +617,1 @@
 

Rather than using Gtk for the test we might be able to use GIMarshalingTests.PropertiesObject which has a large amount of properties. The reason you couldn't get the bug to show up with a regular GObject is likely because dynamically created properties don't have introspection information.
Comment 2 Jonathan Ballet 2013-02-12 22:06:34 UTC
Created attachment 235821 [details] [review]
Correctly set properties on object with statically defined properties
Comment 3 Jonathan Ballet 2013-02-12 22:09:36 UTC
Thanks for the review.

* I added the comments in pygobject.c
* I changed the test to use GIMarshalingTests.PropertiesObject instead, and moved it to the corresponding test_gi.py file
* I also changed the commit message, in relation with the informations you gave me in #1

Note that I'm brand new to PyGObject, so the comment or the commit message might be wrong (:
Comment 4 Jonathan Ballet 2013-02-12 22:13:23 UTC
Created attachment 235822 [details] [review]
Correctly set properties on object with statically defined properties 

My bad, I uploaded an incomplete patch.
Comment 5 Jonathan Ballet 2013-02-12 22:24:31 UTC
Also, note that setting "some_char" instead of "some_uchar" to 54 raises this error here:

   (process:5572): GLib-GObject-CRITICAL **: g_value_set_uchar: assertion `G_VALUE_HOLDS_UCHAR (value)' failed
Comment 6 Simon Feltman 2013-02-12 23:01:58 UTC
Review of attachment 235822 [details] [review]:

Thanks for the updated patch. It seems like the new test would not exercise the first problem mentioned. As that occurs when setting a dynamically defined property with set_properties? So perhaps derive a class from GIMarshallingTests.PropertiesObject with an additional dynamic property and test a mixture of the two with set_properties?
Comment 7 Simon Feltman 2013-02-13 08:32:22 UTC
Commited with a few commit message tweaks.