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 <[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 <[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 > > > > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > > > > > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
