Re: Object referencing in ATK

["Padraig O'Briain" <Padraig Obriain Sun COM>]

Peter,

> Delivered-To: gnome-accessibility-list gnome org
> X-Accept-Language: en
> MIME-Version: 1.0
> Cc: otaylor redhat com, timj gtk org, hp redhat com, 
gnome-accessibility-list gnome org
> Subject: Re: Object referencing in ATK
> Content-Transfer-Encoding: 7bit
> X-BeenThere: gnome-accessibility-list gnome org
> X-Loop: gnome-accessibility-list gnome org
> X-Mailman-Version: 2.0beta5
> List-Id: GNOME accessibility development <gnome-accessibility-list.gnome.org>
> 
> Hi Padraig,
> 
> > I am trying to understand the life cycle of an AtkObject and ensure that
> > it is destroyed when its corresponding GtkWidget is destroyed and that
> > code which uses the ATK interfaces can safely refer to an AtkObject
> > even if its underlying GTK widget has been destroyed.
> > 
> > ...
> > 
> > I an assuming that code which returns an ATK object pointer will be executed
> > in a GTK signal handler and therefore we are guaranteed that the GTK widget
> > underlying the ATK object will continue to exist for the duration of the
> > signal handler.
> > 
> > If someone thinks that this is not a safe assumption, I would appreciate
> > hearing from them.
> 
> I don't think this is safe.  With the latency involved in the multiple layers
> between GTK+ and the AT SPI to the AT itself, I don't think we can insist that
> this be a synchronous operation.  So the signal would fire, the event would be
> queued, the signal handler would return, and then sometime later the AT would 
ge
> the signal and start making queries on the AtkObject source of the signal.  By
> that time the GtkWidget could have been disposed.

As Bill suggested I was not considering that the GtkWidget would be guaranteed 
to be present after a round trip to the AT SPI and the AT.

In fact, after further consideration I do not think I care for how long the GTK 
widget underlying the ATk object continues to exist.

Snnce yesterday I have added a signal handler for "destroy" for the widget in 
gtkaccessible.c which will allow us to NULL the pointer to the widget in the 
GtkAccessible structure and set the state of the ATK object if we wish.

> 
> > If it is desired to make calls which refer to the ATK object subsequently
> > it will be necessary to call g_object_ref() on the ATK object to ensure that
> > it is not finalized and call g_object_unref() when the ATK object is no
> > longer required.
> > 
> > In this scenario, which is similar to adding a reference to an ATK object
> > which is part of an AtkRelation, we could have a situation where the
> > ATK object exists but the GTK widget has been destroyed or finalized.
> > 
> > It seems that we need some way of indicating that the ATK object is unsafe.
> > Looking at GTK it seems that this is done by setting the flags field of
> > GtkObject to GTK_DESTROYED.
> 
> This problem isn't without precedent.  We already anticipate situations in 
which
> AtkObjects are not attached to a GtkWidget - flyweights.  In those cases we 
had
> talked about a TRANSIENT state to indicate this.  An accessible state change
> might be a good way to indicate to an AT that the AtkObject is no longer
> attached to a GtkWidget.
> 

I have not yet got my head around implementing accessible state changes but hope 
to sometime soon.

> And just because the AtkObject isn't attached to a GtkWidget, the AT may still
> want to keep the object around, to make queries about it (about it's last 
known
> state, prior to being disassociated).
> 

As a last resort the AtkObject can be ref'ed to ensure that it is not deleted 
but hopefully we will not need to expose this.

> Finally, don't we have a notion of child destroyed events?  Should not the
> AtkObject referencing the GtkWidget's parent get a child destroyed event 
(sorry,
> signal)?
> 
> > When a GTK widget is destroyed I think that we need to indicate that the
> > current ATK object is destroyed. We also need to ensure that the
> > widget field of GtkAccessible is set to NULL when the widget is destroyed
> > to prevent inappropriate access.
> > 
> > When an accessible object is created by a widget in the GAEL library I
> > propose to connect to the destroy signal of the widget and set the
> > widget field of GtkAccessible to NULL in that signal handler.
> > If the code in the GAEL library which refers to widget field of 
GtkAccessible
> > checks that it is non-NULL before calling it then we will not refer to
> > a destroyed object.
> > 
> > The other question is whether we need to provide a mechanism for a user of
> > the ATK interface to determine whether an ATK object refers to a destroyed
> > object.
> > 
> > If we do I propose to add a state ATK_STATE_DESTROYED to AtkState.
> 
> I wonder if it wouldn't make more sense to change the meaning (and name) of 
the
> TRANSIENT state to something like ATK_STATE_DISASSIOCIATED - to cover the more
> general case that this AtkObject is not associated with an underlying Widget
> (Gtk or otherwise).
> 

My preference is for Bill's suggestion (DEFUNCT is better than DESTROYED as it 
describes the state of the AtkObject rather than the underlying GTK widget) of 
distinguishing between the two states.

Padraig

> 
> Peter Korn
> Sun Accessibility team
> 
> > > Subject: Re: ATK tarball and GTK+ diff tarball
> > > To: otaylor redhat com, Padraig Obriain Sun COM
> > > Cc: timj gtk org, hp redhat com, gnome-accessibility-list gnome org
> > > MIME-Version: 1.0
> > > Content-MD5: 51/9QzJXLA1qTtKY1ccH7w==
> > >
> > > >Owen,
> > > >
> > > >>
> > > >>  * Memory management for AtkRelation/AtkRelationSet obviously
> > > >>    needs some thinking through. Does AtkRelation hold strong
> > > >>    references on the target?
> > > >>
> > > >>    AtkRelation/AtkRelationSet either need to be value objects
> > > >>    that can be copied, or they need to be GObjects, These
> > > >>    are basically the only memory management models that work
> > > >>    for language bindings.
> > > >>
> > > >
> > > >By strong references, do you mean that g_object_ref() has been called on 
the
> > > >AtkObjects in the target? If so, the answer is no.
> > >
> > > FYI, we are re-thinking this, probably we will ref the AtkObjects that are 
in
> > > a RelationSet.  This will likely be a part of the overall overhaul (pardon 
the
> > > phrase) of AtkRelationSet that Padraig is doing at the moment.
> > >
> > > -Bill
> > >
> > > ------
> > > Bill Haneman x19279
> > > Gnome Accessibility / Batik SVG Toolkit
> > > Sun Microsystems Ireland
> > >
> > 
> > _______________________________________________
> > gnome-accessibility-list mailing list
> > gnome-accessibility-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list