GNOME Bugzilla – Bug 469443
Make user_data work across local instances
Last modified: 2019-03-27 20:11:33 UTC
Currently the following code will not work: acc.user_data = 3 child = acc[0] if child.parent.user_data == acc.user_data: print 'worked' else: print 'did not work' To get this to work we have to have something similar to the caching mechanism: A global dictionary that associates user data with accessible object hashes.
Created attachment 94161 [details] [review] Proposed patch Two things that I am not too happy about: 1. The way the event listener for data cleanup is not very elegant. it registers a listener the first time we assign a user_data to an accessible. 2. I'm not sure if looking for the defunct state is bomb proof. For example I don't think top level accessibles emit this.
The global cache of user data objects is fine. As for clean-up, all you need to do is mimick what the code is already doing in the mixin __del__ method for the accessible cache. The events aren't reliable enough for collection and you don't want to throw user data away as soon as the server-side object goes away anyways. You want to tie into the client-side clean-up to throw away the user data. When Python destroys the accessible, your user data will go away too.
Created attachment 94513 [details] [review] Peter's suggestion If run this patch with accerciser, you'll notice that user_data get's scrapped way too early. I'm not sure what is invoking the __del__ method in these cases.
(In reply to comment #3) > If run this patch with accerciser, you'll notice that user_data get's scrapped > way too early. I'm not sure what is invoking the __del__ method in these cases. Needs reference counting per our discussion.
I am not certain where to start this reference counting. __new__ seems premature since we don't have a valid hash value for the accessible yet. __init__ is irrelevant in CORBA object. I could override ref() and unref(), but I don't think these overrides are called internally anyway, so it means explicit reffing/unreffing which is out of the question. I also wrote a patch for pyorbit in bug #471391. But we will need an in-house solution for now.
Created attachment 94946 [details] [review] With pyorbit refounts exposed This patch needs to be used in conjunction with the patch in bug #471391.
(In reply to comment #6) > Created an attachment (id=94946) [edit] > With pyorbit refounts exposed > > This patch needs to be used in conjunction with the patch in bug #471391. I have a minor concern about the dependencies being set up here (mods required to pyorbit to get this working). I believe the main motivation for this change is to handle Orca's desire to maintain its own information about Accessible objects, and its current way to do so is to annotate its orca/atspi.py:Accessible objects directly. Eitan, you mentioned in IRC that there might be some other way to achieve this? Would it still require the use of user_data?
(In reply to comment #7) > I believe the main motivation for this change is to handle Orca's desire to > maintain its own information about Accessible objects, and its current way to > do so is to annotate its orca/atspi.py:Accessible objects directly. Eitan, you > mentioned in IRC that there might be some other way to achieve this? Would it > still require the use of user_data? > I agree %100 about the dependencies concern, I would use the orca_state module for this info. The only problem is if we need to store info, say lastColumn, on more than one accessible at a given time. Does this ever occur?
We have a sweet thing in pyatspi already, no need for this crack for now.