On Thu, 19 Nov 2020 05:54:01 GMT, Sergey Bylokhov <s...@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
