Re: [g-a-devel]Deleting accessible objects

["Padraig O'Briain" <Padraig Obriain sun com>]

Bill, Michael,

When a window is deleted at-poke reports the state of the frame as DEFUNCT so 
the state change is being made.

<digression>
I have logged bug 91957 about at-poke still showing a DEFUNCT frame for the 
deleted window and will commit the proposed patch tomorrow.
</digresssion>

I do not understand the relation between the Accessible in the client and the 
AtkObject in the application. Should calling Accessible_ref and 
Accessible_unref() in the client have an impact on the reference count of the 
AtkObject?

Padraig

> Subject: Re: [g-a-devel]Deleting accessible objects
> To: Michael Meeks <michael ximian com>
> Cc: "Padraig O'Briain" <Padraig Obriain sun com>, accessibility mailing list 
<gnome-accessibility-devel gnome org>
> Content-Transfer-Encoding: 7bit
> Mime-Version: 1.0
> 
> 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
> 
>