Pete, I like the look of the new functions, although it should be noted that each one of the functions with the word "target" should take a type as its first parameter. The intent of attributes and extended states seems similar. I know we don't use them. So, you can get rid of them if you like. Thanks, RG
_____ From: [email protected] [mailto:[email protected]] On Behalf Of Pete Brunet Sent: Friday, February 19, 2010 3:37 PM Cc: 'IA2 List' Subject: Re: [Accessibility-ia2] Relations Thanks Rob and Alex (and those who commented on this back in October). Here is a proposal... 1) Relations - Keep IAccessible2 and IARelation, but deprecate them. - Add IAccessible2_2, with no inheritance to IAccessible or IAccessible2 - remove: nRelations, relations, relation - add the following: - nRelationTargets // if only the first one is needed don't call this so the server doesn't have to calculate it - relationTarget([in] index, [out] IUnknown) // if the index is bad (or index==0 and there are no targets), out parameter is NULL - relationTargets ([in] type, [out] array of IUnknowns) // don't use this if only the first one is needed. Alex, I added the first two methods due to your comment that ATs might only need the first target and this would result in a noticeable performance gain. If this is not a valid scenario I'd prefer to remove those two methods. To the AT devs, would you like the option of iterating via relationTarget rather than iterating through the array returned by relationTargets? I don't think we need a method like localizedRelationType([in] type, [out] localizedType) to convert a relation type to a localized relation type, assuming it's OK to let the ATs localize the 16 relation types, but let me know if you disagree. 2) Attributes (see the email archives from Oct 22 - 26, 2009) - Keep IAccessibleText but deprecate it. - Add IAccessibleText_2. - remove: attributes - add: - HRESULT attributeValue ([in] BSTR name, [out, retval] BSTR *value) - IA2Attribute, a struct containing two BSTRs, one for the name, one for the value - HRESULT attributeList ([out, size_is(,*nAttributes)] IA2Attribute **attributes, [out, retval] long *nAttributes) - Make the same changes to IAccessible2_2, i.e. - remove attributes - add attributeValue, attributeList 3) Extended States There had been talk about removing extendedStates and localizedExtendedStates. From the spec, the definition of "extended state" is: An extended state is a state which is dynamically generated by the application. It is not predefined by the IAccessible2 specification. Does anyone see a need for these? Pete --- Rob Gallo wrote: I'll say a couple of things straight away: IA2_2 should not inherit from IA2. That way we're not tied down by having to implement stubs for legacy functions; the interface will be cleaner; and we don't waste good function names (we can simply change the signatures). And Firefox should not stop supporting IA2. Firefox can support both interfaces, but it can't stop supporting IA2 because of users with older versions of Jaws. Thanks, RG -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alexander Surkov Sent: Wednesday, February 17, 2010 4:53 AM To: Pete Brunet Cc: IA2 List Subject: Re: [Accessibility-ia2] Relations Hi. Pete. I think I'm fine with your suggestion. 1) replace IAccessible2 by new interface 2) change the relation methods 3) change attribute methods However we could return an accessible relation object if we want to save localizing stuffs and an ability for lazy calculation of relation targets (for instance if the client needs the first target only and do not get target count then we could not calculate other targets). In this case we don't need to introduce stuffs like getNextTarget (getNextTarget approach is a bit more evident though). However it would be really nice to get opinion from James and Rob. Thank you. Alex. On Fri, Oct 23, 2009 at 11:48 PM, Pete Brunet <mailto:[email protected]> <[email protected]> wrote: Here is a summary of yesterday's discussions regarding relations Pete - replace IA2 with IA2_2 - remove: nRelations, relations, relation - add: relation ([in] type, [out] IARelation) Carolyn - keep IAccessible2, deprecating nRelations, relations, relation - add IARelationships with 2 methods, relations and relationsForType Jamie - Regarding new IARelationships - It's not clear if Jamie wants to keep the first method Carolyn suggests, i.e. relations - For relationsForType he prefers either - relation ([in] type, [out] IARelation) /* my suggestion */ OR - relation ([in] type, [out] array of IUnknowns), deprecating IARelation - Since we are considering adding support for attributes, this gives weight to IA2_2 - Consider extending IA2_2 via inheriting from IA2 Alex - prefers to not have relations method in the new IARelationships - add getNextTarget My comments... There are actually three reasons to change IAccessible2 1) fix relations 2) fix attributes 3) remove the unneeded inheritance from IAccessilbe If IA2_2 was defined to not inherit from IA2 (and thus not from IA) would the rework on either the client side, server side, or both be too much to warrant the effort? I propose IA2_2 (possibly not inheriting from IA2), - deprecating: nRelations, relations, relation and IARelations - add: relationTargets ([in] type, [out] array of IUnknowns) - note: I didn't list nextTarget (from Alex) but if others feel this is a good method we can discuss it Also, there is no support in this for a localizedRelationType. Is a method needed, i.e. localizedRelation ([in] type, [out] relation)? Pete --- Alexander Surkov wrote: Hi. Thinking from performance point of view and assuming AT don't need all relations always I like more original proposal because it allows to calculate relations lazily. However it could require to extend IAccessibleRelation by method "boolean GetNextTarget(IAccessible **aTarget)" or similarly. So server won't calculate all targets for the given relation type until AT request it. I have not strong opinion if interface should be deprecated or methods. However if we have a practice to deprecate interface entirely (I mean IAccessibleTable interface) then we should follow it. I like IAccessible2_2, that's probably the best. Though I'd happy to hear better one :) It's more evident than IAccessible22. However we append '2' in the end of interface name like in the case of IAccessibleTable2. Therefore IAccessible22 should be more logically correct but it may confuse. On the another hand our successors could really invent IAccessible22 specification in 1000 years :). As well IAccessible2_2 it's more correct than IAccessible3 because IAccessible2 has additional meanings of set of interfaces or specification. Thank you. Alex. On Fri, Oct 23, 2009 at 7:00 AM, James Teh <mailto:[email protected]> <[email protected]> wrote: On 23/10/2009 1:03 AM, Carolyn MacLeod wrote: I think deprecating IAccessible2 would be really confusing to everyone, no matter what the new interface's name is. Agreed, although there may be sufficient justification; ee below. Perhaps something like this might be a bit less wild? - deprecate IAccessible2::nRelations, relation, relations - add IAccessibleRelationships I think this makes sense if this is the only reason we are deprecating IAccessible2. > (although I guess then AT's would have to QI or QS to get an object's > relations, which is more work for a pretty common thing...) QI isn't so bad. Certainly, I think QS would be a bad thing. which has only 2 methods: relations and relationsForType I'm more for Pete's original suggestion; i.e. HRESULT relation ([in] BSTR *relationType, [out, retval] IAccessibleRelation **relation) Remember that IAccessibleRelation accounts for multiple targets. Another idea is to deprecate IAccessibleRelation altogether and just have the relation() method return an array of targets for the specified type, similar to IAccessibleTableCell::columnHeaderCells. The question is: when retrieving relations, is it fair to assume that an AT wants all targets in the majority of cases? If this is an incorrect assumption, then this would be less efficient. With regard to deprecating IAccessible2: If it was just relations, I would think a new interface (as proposed here) is fine. However, if we want a new interface for attributes as well (see Pete's previous email), that's two new "add-on" interfaces replacing deprecated functionality. In that case, perhaps it is time to consider deprecating IAccessible2. However, I agree that this would be a total pain for everyone involved. The Microsoft approach is generally to subclass the old interface and just add the new methods to the subclassed interface, rather than replacing it altogether. See MSHTML for example. 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
