GNOME Bugzilla – Bug 433011
Who implements Collection?
Last modified: 2012-12-21 17:07:52 UTC
I'm adding these thread for having a place of discussion on who is supposed to implement Collection. Right now the patch I will be posting in a few minutes let Document and Application to implement it. According to this link: http://lists.freestandards.org/pipermail/accessibility-atspi/2006-June/000322.html Document is the first thing to implement and also table. What else I am missing? ariel
Created attachment 86925 [details] [review] Application and document implement collection This patch makes the bridge to implement collection for every launched application. Also, on libspi, everytime a SpiDocument is created we implement collection for that document. Some additionals corrections to SpiCollection have been made to make it work under pyorbit.
I think Collection should be implemented on any container type object. So I would include the following: Certainly these: application frame document frame table Possibly these: form pane/split pane window tree combobox
For me Frame, Document Frame, table and window. Application doesn't make sense because AFAIK Application only one has child.
I'm not sure exactly what should implement Collection. I guess the first thing I'd like to ask is "why can't *everything* implement Collection?" :-)
I agree with Will and have always believed collection should just be available from any node. This is similar to HTML where any element can be a starting point for things like GetElementsByTagName(). It's darn useful to be able to start from anywhere and it doesn't cost the implementation much to do that, as far as I can tell.
I am not sure whether this is helpful. There are certain nodes that don't have children or usually only have one I don't see the use of adding collections on nodes where we now we are not going to get anything back. My thought is that only container objects should implement collection. Aaron is right saying that adding collection to every node is very easy to do.
(In reply to comment #6) > nodes where we now we are not going to get anything back. My thought is that > only container objects should implement collection. Is this mostly a philosophical thought or are there technical reasons for why putting collection on everything would be a really bad idea?
IIRC, Bill thought you might not want to walk into something other documents -- other things that use collection. For example if you are starting at the root of a browser UI you might not want to walk into page content. The big disadvantage of this is that if you really do want to walk into everything you now need to first collect the collections. I think it's better to walk through everything by default and let the collection user say what not to walk into, if that's really important at that moment. Perhaps depending on what collection is being used for you might be able to have better performance by avoiding certain subtrees. But I can't think of anything very compelling at the moment.
> I think it's better to walk through everything by default and let the > collection user say what not to walk into, if that's really important at that > moment. Perhaps depending on what collection is being used for you might be > able to have better performance by avoiding certain subtrees. Performance increases by not visiting subtrees is something that Will and I discussed. There has to be many examples where we might want to skip lists and comboboxes, perhaps even tables or internal frames.
Scott, but I imagine you as the caller want to be in control of what's skipped, right? And that by default it's better just to visit everything?
(In reply to comment #10) > Scott, but I imagine you as the caller want to be in control of what's skipped, > right? And that by default it's better just to visit everything? > I absolutely agree. Visiting everything by default is best but as a caller I might want control. Unfortunately, the caller does not have control now. I envision a search method that takes a second matchRule that would be used to determine if an object should be recursed. I'm not sure if the performance hit of checking the second matchRule would outweigh any performance benefits of not recursing some objects. Testing and use case analysis would need to be done.
>IIRC, Bill thought you might not want to walk into something other documents -- >other things that use collection. For example if you are starting at the root >of a browser UI you might not want to walk into page content. The big >disadvantage of this is that if you really do want to walk into everything you >now need to first collect the collections. Yes. Actually that one was the very first test case I was supposed to look for, i.e. to be able to first query for all of the collections. That is not as bad as it looks, because at that time a collection didn't traverse into other collections -we now have the option of doing so. This query actually is a very fast one. >I think it's better to walk through everything by default and let the >collection user say what not to walk into, if that's really important at that >moment. This can't be done right now. Also, having this option will slow things as we would have to check if every node implements or is the condition to avoid.
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
Closing this bug as OBSOLETE. 1. AtspiCollection applies to (and is implemented for) all containers at the moment. 2. AtkCollection will be forthcoming. Nothing more to discuss here.