<AWT Dev> RFR: 8256108: Create implementation for NSAccessibilityElement protocol peer [v2]

[Alexander Zuev]

On Thu, 19 Nov 2020 05:54:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Implementing it step by step is exactly why i did it - if i make JavaComponentAccessibility implementing the NSAccessibilityElement it triggers mac os to stop using the old property based API on all of it and we are not ready for that. I'm planning to keep CommonComponentAccessibility implementation minimal so once all of our bases are covered we can just swap JavaComponentAccessibility to implementing NSAccessibilityElement and switching all the subcomponent's peers to extend it and then we will be able to drop CommonComponentAccessibility altogether (or just leave it so we can swap to older API easier for comparison testing).
>
> Then it does not look like as step by step implementation, it just adding the code which does not necessarily work properly. Are you sure that the implementation of NSAccessibilityElement will block the old for all roles not only for the elemental role? It will be useful if we start to use the new accessibilityFrame/etc API instead of accessibilityPositionAttribute/etc attributes, but still, use the old attributes for other roles.
> 
> If the plan is to make the CommonComponentAccessibility as small as possible then the CommonComponentAccessibility.accessibilityFrame could be implemented on top of accessibilityPositionAttribute+accessibilitySizeAttribute or another way around, similar to accessibilityParent which is implemented via accessibilityParentAttribute. But in this case, the whole class will have 5 rows which are never executed? Probably it is possible to mix old/new?
> 
>> 
> Note
> 
>> The new, method-based accessibility API is backward compatible with the previous, key-based API. This means, if you have controls that are already accessible, you can continue to use them. You can even convert a control to the method-based API in stages, implementing the new method-based API for some features, leaving others in the key-based API.
> 
>> If there’s a conflict between the method- and key-based APIs, the method-based API takes precedence. This is particularly important for frameworks that provides accessible controls. If you convert those controls to the method-based API, the system ignores any legacy code that modifies their attributes. For this reason, if you create third-party libraries, you may want to wait to upgrade your library until you’re sure that all your clients have updated their apps.
> https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/

It is step by step implementation since the component peers will inherit these functions and they will be called once we initialize these peers. It will be clear once you see simple peer like pushbutton peer implementation. And yes - i tested - once system detects that peer implement new protocol it stops calling the property retrieving methods giving out "unrecognized selector sent to instance" errors for not implemented functions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1290