Re: [g-a-devel]Deleting accessible objects
- From: Bill Haneman <bill haneman sun com>
- To: Michael Meeks <michael ximian com>
- Cc: "Padraig O'Briain" <Padraig Obriain sun com>, accessibility mailing list <gnome-accessibility-devel gnome org>
- Subject: Re: [g-a-devel]Deleting accessible objects
- Date: 29 Aug 2002 12:56:52 +0100
On Thu, 2002-08-29 at 13:07, Michael Meeks wrote:
> Hi Padraig,
>
> On Wed, 2002-08-28 at 16:52, Padraig O'Briain wrote:
> > I have been running gtk-demo with at-poke. I cause a window to be created in
> > gtk-demo, and examine its contents to ensure that accessible obecjts are created
> > and then delete the window. I would expect to see GAIL obejcts being deleted in
> > gtk-demo but I have not seen any evidence of GAIL objects being deleted when the
> > corresponding widgets are deleted.
> >
> > Should these GAIL obejcts be deleted?
>
> Well; there are 2 points here.
>
> It seems to me that there is 0 point in keeping around a heavy
> CORBA/Bonobo proxy for an otherwise dead AtkObject - so I think
> (personally) that coupling the lifecycle of the BonoboObject primarily
> to the AtkObject, and secondarily to the reference count would make more
> sense than the current setup.
Hmm, well at the moment we use state information for determining when an
at-spi accessible object is 'defunct'. At the moment a client
application receives (or should receive) notification when this happens,
via a state change on the object (to state DEFUNCT). It's the client's
responsibility to unref the object in this case.
Personally I don't think this is so bad; though I can see the attraction
of just destroying the proxy and relying on CORBA exceptions to inform
the client of object death, the current model gives the client better
information on why the object died - at least if it's working as I think
we intended.
It's possible that we handle the case of a destroyed widget correctly,
but somehow are accidentally holding a reference to the GtkWidget in
case where we should not, and thus might be preventing the finalize code
from triggering the state change to DEFUNCT.
I'd suggest we check to see whether state-changed event for the unmapped
window is getting fired, and make sure the window gets destroyed by the
app if we haven't loaded accessibility, etc.
-Bill
> Secondly - there are 3 places there may be a bug:
>
> a) libspi/ g_object reference counting - perhaps we leak a
> reference here, and the BonoboObject peer doesn't release it.
>
> b) cspi/ perhaps we don't release the remote reference correctly
> when we quit.
>
> c) most likely - at-poke has an Accessible_ref / unref leak
> somewhere. I believe if you exit the app it should auto-cleanup
>
>
> --
> mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]