Re: [g-a-devel]HEADS-UP: at-spi event refcount change
- From: Michael Meeks <michael ximian com>
- To: David Bolter <david bolter utoronto ca>
- Cc: Bill Haneman <bill haneman sun com>, accessibility mailing list <gnome-accessibility-devel gnome org>
- Subject: Re: [g-a-devel]HEADS-UP: at-spi event refcount change
- Date: 20 Jul 2002 14:47:03 -0400
Hi David,
On Wed, 2002-07-17 at 11:32, David Bolter wrote:
> I am not sure if I am clear on the ref issue. Please consider: when I
> am storing accessibles, for example, when we get a focus event, we walk
> up the tree and store a pointer to the root accessible (application),
Again, again, I suggest that we vitally need to be able to listen to
only events on a sub-tree of accessibles.
> and then when we get another focus event, we walk up to the root, and
> check it against our stored pointer. So if we are using the cspi
> bindings, we should add a ref presumably using Accessible_ref?
You should use Accessible_ref - and you don't need to care whatsoever
about the underlying reference model - really; don't worry about it :-)
Clearly - if you want to store your own copy of a reference that you're
passed in an event handler, it's only live for the scope of that event
handler - thus you will need to use Accessible_ref but that can't be
avoided.
> When we are no longer concerned with an accessible do we unref?
Yes.
> and if so, when does it become invalid?
That's irrelevant - why should you care ? you don't hold a reference to
it - yes ? or you wouldn't be holding a ref.
> Presumably when the ref count is zero, but I
> have seen discussions that have led me to believe this is not the case?
It shouldn't matter - it should be an implementation detail. It's
really an efficiency detail of the server implementation, and a widget
lifecycle thing.
> So I guess I can't help but be curious how things are done, even though
> it shouldn't affect the gok, it is reassuring to know what is going on
> underneath. But I could always look at the code ;-)
Accessible_ref/unref does a client side cache of
Bonobo_Unknown_ref/unref which controls remote lifecycle. Ultimately
this is the least of your problems - you _really_ don't want to be doing
the roundtrips to walk up to the tree root more than absolutely
necessary - each one involves 2+ context switches & IPC.
Can you specify precisely why you need to walk up the tree like that ?
> Also, I was pleased to see that the events are synchronous and ordered,
> and I do believe that is relevant to the gok. We have had problems with
> collisions in the past.
Good, I'm glad it's fixed for you,
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]