Hi Pete, I can answer some of these to at least some extent.
On 21/10/2009 2:16 AM, Pete Brunet wrote: > 1) Why were IATable2 and IATableCell requested and why wasn't IATable a > suitable solution? * IATable provided a somewhat obscure mechanism for retrieving table headers, returning an IATable object for the headers. If multiple column headers were to be returned, this would probably require a "virtual" table to be created by the app. It was felt that a simpler, more direct way was needed to retrieve row and column headers. * Many IATable methods took a table cell index as a parameter. It was felt that it would be much easier to just pass in the object for the required cell, since most of the time, a client already has the cell object anyway when querying for further information. * IATableCell provides a simple, direct way to retrieve the table from its cells. Previously, a client had to crawl up the object hierarchy to find the table, which is somewhat obscure and tedious at best. > Does ATK need similar changes? If ATK's table interface is virtually equivalent to IATable, then yes, I would argue that it does. NNote that I'm not familiar with ATK's table interface, so this one's for Alex. :) > 2) When IA2 started a goal was to make it as close as possible to ATK so > when IA2 was released it was as close to ATK as could be accomplished. > What has changed in IA2 between the initial release of IA2 and now that > should be considered for incorporation back into ATK? I don't think any new interfaces have been added to IA2 since its initial release, so it follows that no new methods have been added. For the most part, it has been documentation clarifications. > 3) Are there areas that need improvement in either IA2 or ATK (or both)? I can't speak for ATK, but for IA2: * IAHyperlink: A discussion was started regarding the derivation of IAHyperlink from IAAction. In short, I feel that this derivation infers that a hyperlink can only have one action. However, we never came to a conclusion on what should be done there. * Relations: I think the current mechanism for relations is rather suboptimal at best. A client cannot retrieve a relation by its type, which is I think the most common request. For example, a client can't ask specifically for the "controlledBy" relation. Instead, the client must request all relations in one shot or crawl through the individual relations until it finds the one it requires. This is also inefficient on the server side, because the server then has to create relation objects which will probably never even be used. For this reason, NVDA never uses the current IA2 relation mechanism and instead uses Gecko's special relation constants for IAccessible::accNavigate. Jamie -- James Teh Email/MSN Messenger/Jabber: [email protected] Web site: http://www.jantrid.net/ _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
