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

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

> Subject: Re: [g-a-devel]Deleting accessible objects
> To: "Padraig O'Briain" <Padraig Obriain sun com>
> Cc: michael ximian com, gnome-accessibility-devel gnome org
> Content-Transfer-Encoding: 7bit
> Mime-Version: 1.0
> 
> On Thu, 2002-08-29 at 14:03, Padraig O'Briain wrote:
> > Bill, Michael,
> > 
> > When a window is deleted at-poke reports the state of the frame as DEFUNCT 
so 
> > the state change is being made.
> 
> cool, that sounds right to me.
>  
> > <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?
> 
> Only in this sense: when an Accessible (bonobo 'at-spi' object) has a
> positive refcount one would keep the atkobject around, decrementing the
> refcount of the Accessible to zero should decrement the atkobject
> refcount.  I think however that the atkobject refcount should remain
> positive while the backing widget is alive, thus I think that an
> atkobject in the 'normal' case with a live Accessible should have a
> refcount of two, and the acts of destroying the backing widget and of
> unreffing the Accessible to zero should decrement the refcount.  I would
> expect that this means that the sequence of events
> 
> widget is destroyed->atkobject state changes->client unrefs Accessible


The idea of unreffing when the state changes to DEFUNCT is new to me. I will see 
what impact it has.


> would result in two atkobject unrefs.
> 
> WHat have I forgotten? :-)
> 
> -Bill
[SNIP]