Re: [g-a-devel]HEADS-UP: at-spi event refcount change



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]