I would guess localized... methods were reserved for the future custom (user-defined) relations, roles and etc, specified, for example, via ARIA.
Alex. On Mon, Nov 2, 2009 at 3:42 AM, Carolyn MacLeod <[email protected]>wrote: > > Realistically, do ATs ever call localizedRelationType? > I was thinking that it was a bit excessive to require every application to > localize the same constant set of strings. > It would seem "closer to the user" to just leave it up to the AT whether > those strings need to be localized or not. > > Carolyn > > > From: Alexander Surkov <[email protected]> To: > Pete Brunet <[email protected]> > Cc: > IA2 List <[email protected]> > Date: 26/10/2009 06:25 AM Subject: Re: [Accessibility-ia2] Relations > Sent by: [email protected] > ------------------------------ > > > > Hello. > > If AT needs IAccessibleRelation::localizedRelationType (however it's > not implemented in Firefox for example and no idea what AT expects > actually) then we can't drop IAccessibleRelation and introduce > "relationTargets ([in] type, [out] array of IUnknowns)", but instead > it should be "relationTargets ([in] type, [out] array of > IAccessibleRelation)". > > Concerning to IAccessibleRelation::getNextTarget, it's worth to > introduce if there are cases when AT wants to get only one relation > even if several ones are available. For example, if AT wants to speak > the first relations and speak next relations on user demand only. > > 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 > > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
