Re: [g-a-devel] Need ATK experienced help

["Quiring, Sam" <Sam Quiring windriver com>]

Hello Li,

You asked "is there a cache?"  A cache of what?  Can you explain
how that would make a difference?  Or point me at some docs?

In the AtkObject's managed by PAPI, each parent maintains a list
of its children, in addition to anything ATK is doing.

ref_child:

1.  From the atkParent, get the associated GUI node
2.  Find the Ith GUI child node of the parent GUI node
3.  create atkChild, an AtkObject corresponsing to the child GUI node
4.  set the parent:  atk_object_set_parent(atkChild, atkParent)

Here's the (paraphrased) Papi code in set_parent showing that a list
of child nodes is maintained in each parent:

    atk_object_set_parent(atkChild, atkParent);

    /* Add the object to the list of children of the parent. */
    data = g_object_get_data (G_OBJECT (atkParent), PAPI_CHILDREN);
    data = g_list_append (data, atkChild);
    g_object_set_data (G_OBJECT (atkParent), PAPI_CHILDREN, data);

-Sam
 

-----Original Message-----
From: Li Yuan sun com [mailto:Li Yuan sun com] 
Sent: Wednesday, September 02, 2009 2:58 AM
To: Quiring, Sam
Cc: Gnome-accessibility-devel gnome org
Subject: Re: [g-a-devel] Need ATK experienced help

Hi Quiring,

How did you implement ref_child function? Is there a cache?

Li

On Tue, 2009-09-01 at 14:21 -0700, Quiring, Sam wrote:
> Greetings,
>  
> I'm adding ATK support to a Python platform that implements its own
> graphics library from scratch.  I'm using Papi, which has been really
> excellent.
>  
> I've just finished implementing some of the ATK support.  ATK objects
> (actually, papi.atk.AtkObject's) are created on demand.  When an
> ATK request comes in for the Nth child of an ATK node (via the ATK
> callback AtkObjectClass.ref_child), I examine the associated GUI
> node's children, find the Nth one, and create a corresponding ATK node
> for it, which I pass back to the caller.
>  
> One client I'm using to test this is an AT-SPI dump program I wrote a
> while ago.  It dumps the entire AT-SPI tree to a file.
>  
> Here's my problem:
>  
> I bring up the Python platform with the initial screen GUI.  I run my
> AT-SPI dump client program.  The dump is beautiful.  I run it again.
> The Python ATK support crashes with errors in the Python log like
> this:
>  
> ** (process:2857): CRITICAL **: get_atkobject_from_servant: assertion
> `ATK_IS_OBJECT(object->gobj)' failed
> ** (process:2857): CRITICAL **:
> impl_accessibility_accessible_get_name: assertion `object != NULL'
> failed
> ** (process:2857): CRITICAL **: get_atkobject_from_servant: assertion
> `ATK_IS_OBJECT(object->gobj)' failed
> ** (process:2857): CRITICAL **:
> impl_accessibility_accessible_get_description: assertion `object !=
> NULL' failed
> ** (process:2857): CRITICAL **: get_atkobject_from_servant: assertion
> `ATK_IS_OBJECT(object->gobj)' failed
> 
> The first time I run the client, my ATK Python support is building the
> ATK nodes on demand.  Those nodes are saved and the second time I run
> the client all the ATK nodes should exist.  And they do.  But
> somewhere in between, the first 12 bytes of memory in some of the ATK
> nodes is getting trashed.  In this case I'm talking about the real ATK
> node, the one pointed to by the papi.atk.AtkObject.
>  
> Here are some odd facts:
>  
> I wrote a routine in Python to run though the entire
> papi.atk.AtkObject tree and dump each node and it's parent (parent
> obtained via ATK call). I dumped the tree before and after the memory
> got trashed. In the before dump, every node's parent displays.  In the
> after dump, the leaf nodes cannot find their parent as a result of
> memory being trashed.  But interior nodes are ok.
>  
> To make ATK do stuff, my Python program must call a Papi routine
> (papi.atk.iterate()) over and over in the main GUI loop.  I put some
> checking code around this call examining one particular node which I
> knew would get trashed.  Before one iteration step the node is fine,
> afterwards, the node is trashed.  Is there any way I can figure out
> what action was performed by that iteration step?
>  
> Does this describe a situation familiar to anyone?  It has some
> symptoms of garbage collection, as if the leaf ATK nodes don't have
> the proper ref count.  But the "fact" that the memory seems to be
> trashed by an iteration of ATK main loop doesn't seem consistent with
> garbage collection.
>  
> Any suggestions would be appreciated.
>  
> -Sam
>  
>  
>  
>  
>  
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel