Re: [g-a-devel]Accessibles lifetime & events order''

[gnome-accessibility-devel bernard-hugueney org]

Le Lundi 22 Septembre 2003 12:18, Bill Haneman a écrit :
> Bonjour Bernard:

Thank you very much for your reply !

>
> It's a little hard to tell from the code you posted - I assume it's
> pseudocode ?  An actual code sample might be more helpful, since
> your code contains "C++-isms".

First thing I've done was writing a C++ wrapper around libcspi.
It allows me to manage shared dynamic Accessible easly thanks to smart 
pointers (boost::shared_ptr), calling Accessible_unref upon 
destruction. 


>
> If you are using the simplified C bindings ('cspi') of at-spi, then
> the pointers you receive from various 'getAccessible' calls such as
> Accessible_getParent (Accessible *acc) should be compare-able and
> unique during their lifetime.  These pointers _do_ get reused, but
> not while you are holding a reference to them.  These are the same
> sort of pointer which is contained in the event structure.

Ok.

>
> This pointer is guaranteed valid ONLY during the event emission
> unless you explicitly "ref" it - the same is true for all
> Accessible objects. You don't ordinarily need to "ref" the
> Accessible you get from "getChild/getParent/etc." since those calls
> increment the reference count of the Accessible being returned (as
> the documentation indicates). This means of course that you should
> call "Accessible_unref" on Accessible pointers when you are done
> with them.  You can also "ref" an AccessibleEvent, which has the
> effect of holding a reference to the Accessible and keeping the
> AccessibleEvent data valid until you do an 'unref' on it.  If you
> find places in the API documentation for cspi which doesn't
> indicate whether a return Accessible value is a reference or not
> (i.e. whether the call has incremented the reference count), please
> file a bug about that.

Thank you for your explaination, it confort my understanding. (I have 
NO leak nor illegal acces, event while catching every event, then 
getting every interface of every parent). The grey area is still 
about "transitivity" of lifetime :
when I get an AccessibleEvent*, it's ->source is valid.
when I get an Accessible* with getChild/getParent, ts is valid and 
will stay so until I release the reference with Accessible_unref.
However, I is still not clear (sorry for being dense :-( ) wether the 
fact that my source is valid garantees that I will be able to get 
valid parents & child. If I can get them with getChild & getParent, I 
know they will be valid, but can I get them ?
If a hierarchy of accessibles goes defunct. Will the whole hierarchy 
stay valid until the last event linked (even remotely) to the last 
Accessible is processed ?

Exemple: A is the parent of B and B is the parent of C.
They all get defunct.
I will get 3 defunct events (one for each).

Is there any garantee on the order of thoses events ?
(Child first? parent first ?)

From the sources of each defunct event I could get access to the other 
2 (with getParent/getChild). But is it allowed ?
If not, what is allowed/garanteed ? (only getParent?)

>
> If you don't explicitly 'ref' AccessibleEvents, then you cannot
> safely reuse their member Accessible* pointers or AccessibleEvents.
>  You can however make calls on the 'source' of an event
> inside/during that event's emission handler.  You should not make
> calls on an Accessible which you received from a '..getAccessible'
> or 'getParent' call unless you hold a reference to it, so don't
> call these APIs after calling "Accessible_unref" of course.
>
> As you have discovered, the 'defunct' state can be useful for
> determining whether an Accessible's UI component has been destroyed
> since you obtained the reference.  Calling cspi methods on defunct
> objects can result in errors but they should be non-fatal.

Well, all I can say is that it certainly has been fatal in the past. 
However, I do not have errors with current CVS.

>
> Perhaps you are already doing all of the above, and I am
> misunderstanding your problem, but I cannot tell from the code you
> posted.

Sorry for not being explicit. However, I was very pleased and 
reassured that you clearly stated what I infered from trial and docs.


>
> Lastly, I would strongly recommend that for performance reasons you
> do not traverse the accessibility hierarchy upwards for every event
> in anything but a test program.  This operation is likely to be
> quite 'expensive'.  If you need to know the context of every event,
> it is probably better to compare the sources against cached
> Accessible pointer values such as 'most-recently-focussed', etc.
> and rely on "window:" events to inform you of changes in
> topleve-window context.

Trust me I couldn't agree more!
(tracing OpenOffice on an old laptop !)
I decided to go first for the simple & correct.
Being correct was not so simple :-(
Version .2 will cache Accessible trees. (a la at-poke).

Thank you very much for your explainations. I think the only questions 
remaining are thoses I raised with my little example (A->B->C).


Bernard.