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 661359 - Something is wrong with editing-started signal
Something is wrong with editing-started signal
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
Git master
Other Linux
: Normal critical
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
: 660196 661671 662135 (view as bug list)
Depends on:
Blocks: 660099 693111
 
 
Reported: 2011-10-10 09:14 UTC by Ignacio Casal Quinteiro (nacho)
Modified: 2013-02-05 15:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tree view (762 bytes, text/plain)
2011-10-10 09:14 UTC, Ignacio Casal Quinteiro (nacho)
  Details
when converting an object with transfer none, make sure the wrapper owns a ref (1.26 KB, patch)
2011-10-14 20:43 UTC, johnp
none Details | Review
unit test for checking ref count of object param in signals (1.07 KB, patch)
2011-10-14 21:20 UTC, johnp
none Details | Review

Description Ignacio Casal Quinteiro (nacho) 2011-10-10 09:14:46 UTC
Created attachment 198701 [details]
tree view

I am attaching a test case, see that if you click on the cell to edit it a warning is provided. Something like:


(gedit:11919): Gtk-CRITICAL **: gtk_cell_area_activate_cell: assertion `GTK_IS_CELL_EDITABLE (editable_widget)' failed

Might be that editable is an interface btw.
Comment 1 Ignacio Casal Quinteiro (nacho) 2011-10-13 14:32:32 UTC
*** Bug 661671 has been marked as a duplicate of this bug. ***
Comment 2 johnp 2011-10-14 19:22:11 UTC
So if you get rid of the start signal it works.  We are somehow refcounting wrong here.  The issue happens when the cell creates a entry widget with a refcount of 1.  It then passes this widget to the on_view_label_cell_editing_started python signal handler.  At the end of the handler we unref the widget even though we don't own it.  This could be an annotation issue or something deeper.
Comment 3 johnp 2011-10-14 20:43:54 UTC
Created attachment 199033 [details] [review]
when converting an object with transfer none, make sure the wrapper owns a ref
Comment 4 johnp 2011-10-14 20:44:51 UTC
Patch fixes refcount signal issue.  Please test.  Looking to add a unit test
Comment 5 johnp 2011-10-14 21:20:29 UTC
Created attachment 199037 [details] [review]
unit test for checking ref count of object param in signals
Comment 6 johnp 2011-10-14 21:21:19 UTC
Unit test needs new GI from head but I didn't up the required version since runtime doesn't need it
Comment 7 johnp 2011-10-14 21:51:05 UTC
*** Bug 660196 has been marked as a duplicate of this bug. ***
Comment 8 Ignacio Casal Quinteiro (nacho) 2011-10-15 08:22:31 UTC
It works now, although I get some warnings pointed below, I guess that this is another bug. Or maybe is related with your patch...

(gedit:4235): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(gedit:4235): GLib-GObject-CRITICAL **: g_value_set_object: assertion `G_IS_OBJECT (v_object)' failed

(gedit:4235): GLib-GObject-CRITICAL **: g_object_weak_ref: assertion `G_IS_OBJECT (object)' failed

** (gedit:4235): CRITICAL **: atk_object_add_relationship: assertion `ATK_IS_OBJECT (object)' failed

(gedit:4235): GLib-GObject-CRITICAL **: g_object_weak_unref: assertion `G_IS_OBJECT (object)' failed

(gedit:4235): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(gedit:4235): GLib-GObject-CRITICAL **: g_value_set_object: assertion `G_IS_OBJECT (v_object)' failed

(gedit:4235): GLib-GObject-CRITICAL **: g_object_weak_ref: assertion `G_IS_OBJECT (object)' failed

** (gedit:4235): CRITICAL **: atk_object_add_relationship: assertion `ATK_IS_OBJECT (object)' failed

(gedit:4235): GLib-GObject-CRITICAL **: g_object_weak_unref: assertion `G_IS_OBJECT (object)' failed
Comment 9 Ignacio Casal Quinteiro (nacho) 2011-10-15 13:37:56 UTC
So after checking the bt, seems that it is a problem with accesibility. This fixes the problem thanks.
Comment 10 Ignacio Casal Quinteiro (nacho) 2011-10-18 22:21:20 UTC
*** Bug 662135 has been marked as a duplicate of this bug. ***
Comment 11 Ignacio Casal Quinteiro (nacho) 2011-10-21 13:07:33 UTC
I think there is something broken here now, I get:


======================================================================
ERROR: test_object_param_signal (test_everything.TestSignals)
----------------------------------------------------------------------
Traceback (most recent call last):
  • File "/home/nacho/checkout/gnome/pygobject/tests/test_everything.py", line 495 in test_object_param_signal
    obj.connect('sig-with-obj', callback)
TypeError: <TestObj object at 0x12418c0 (RegressTestObj at 0x12c9400)>: unknown signal name: sig-with-obj

Comment 12 Ignacio Casal Quinteiro (nacho) 2011-10-21 13:15:17 UTC
So the problem is that the patch for this test is in g-i master but not in gnome-3-2. We will need a g-i release before we can release pygobject.
Comment 13 johnp 2011-10-24 17:17:34 UTC
I think I already discussed this with you.  As long as the tests pass on the developers system we can do the release.  If we feel this is wrong we need to setup a two tiered system were we add tests to pygobject itself and once we have a release of gobject-introspeciton we switch to using that.
Comment 14 Ignacio Casal Quinteiro (nacho) 2011-10-24 17:20:41 UTC
yup, I sent that comment before we spoke by IRC. The release was already done.