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 158708 - Warning message when gnome-window-properties exits.
Warning message when gnome-window-properties exits.
Status: RESOLVED FIXED
Product: libglade
Classification: Deprecated
Component: gtk
unspecified
Other opensolaris
: Normal normal
: ---
Assigned To: James Henstridge
James Henstridge
: 159745 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-11-19 13:26 UTC by padraig.obriain
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (1.46 KB, patch)
2004-11-19 15:37 UTC, padraig.obriain
none Details | Review

Description padraig.obriain 2004-11-19 13:26:47 UTC
Start gnome-window-properties in a terminal with with accessibility enabled.
Then press Close button. Warning messaged is emitted:

anymachine:/export/home/padraigo/spec-files 27 % gnome-window-properties
GTK Accessibility Module initialized
Bonobo accessibility support initialized

(gnome-window-properties:4487): GLib-GObject-WARNING **: ???: couldn't find weak
ref feade4d0(2adc8)
Comment 1 padraig.obriain 2004-11-19 15:36:53 UTC
When an AtkRelation is created a weak reference is added to handle the case
where the AtkObject in the relation is destroyed.

In libglade there is code which adds an object to the GPtrArray of an
AtkRelation. In this case the weak reference is not added. The warning message
is complaining about the missing weak reference when the relation is being
destroyed.

I have a patch for libgalde which fixes the problem.
Comment 2 padraig.obriain 2004-11-19 15:37:33 UTC
Created attachment 33935 [details] [review]
Proposed patch
Comment 3 James Henstridge 2004-11-19 16:07:44 UTC
Is this patch appropriate for use with GTK 2.4 as well as GTK 2.6?

Also, would it make sense to add an atk_relation_set_add_relation() function to
ATK similar to the add_relation() function in libglade for the GTK 2.6
development cycle?

I realise that the add_relation() code isn't particularly pretty, but there
isn't any other obvious way to handle this (manipulating the target array
directly always seemed like a bad API).  Being able to call a simple API to add
relations from Libglade would make the code more resistant to these sort of
changes inside ATK in the future.
Comment 4 bill.haneman 2004-11-19 16:43:58 UTC
I don't understand why you were manipulating the array in the first place. 
Adding relations to sets is not something that happens in many places (though of
course in libglade it does happen frequently....).  The expected case would be

atk_relation_set_remove (relations, relation);
g_object_unref (relation);
relation = atk_relation_new (...);
atk_relation_set_add (relations, relation);

However I think the suggested API addition is reasonable and useful, certainly
for libglade.
Comment 5 padraig.obriain 2004-11-19 17:27:44 UTC
See bug #158722 for new API. It will be fixed in ATK 1.9.x which is targeted as
GNOME 2.10.

I believe that the patch for libglade is appropriate for use with GTK 2.4.
Comment 6 padraig.obriain 2004-11-29 09:24:29 UTC
*** Bug 159745 has been marked as a duplicate of this bug. ***
Comment 7 James Henstridge 2004-11-29 11:06:15 UTC
Okay, I've fixed this in CVS and released 2.4.1 and 2.5.0 tarballs.  After
rolling the 2.5.0 tarball, I updated CVS to use the new
atk_relation_set_add_relation_by_type() API (which hasn't been included in any
tarball releases yet).

It seems weird that atk_relation_get_target() returns a GPtrArray though.  If it
was meant to be read only, surely a better prototype would have been this:
  AtkObject **atk_relation_get_target (AtkRelation *relation,
                                       gint        *n_targets);
(this also gives you a level of type safety).

Since GPtrArray is an extendable array and there was no other API for adding
targets, I assumed that adding to the GPtrArray was the intended way of doing so.