Add implementations for NSAccessibility... classes

[gcasa]

No description provided.

[Copilot]

Pull Request Overview

Implements core NSAccessibility classes and C helpers to make accessibility elements, custom rotors, and custom actions functional under manual retain/release.

• Add concrete initializers, accessors, and simple role description to NSAccessibilityElement
• Implement NSAccessibilityCustomRotor and ItemResult, plus NSAccessibilityCustomAction (with block support, perform logic, and factories)
• Provide basic NSAccessibility* C helpers for notifications and role/action descriptions

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 10 comments.

Show a summary per file

File	Description
Source/NSAccessibilityElement.m	Implements element initializers, accessors, dealloc, and a simple role description.
Source/NSAccessibilityCustomRotor.m	Fills in rotor and item result initializers, accessors, and dealloc.
Source/NSAccessibilityCustomAction.m	Adds safe block retention/release, perform logic, convenience factories, and description.
Source/NSAccessibility.m	Adds basic implementations for posting notifications and role/action description utilities.
Headers/AppKit/NSAccessibilityElement.h	Public API and ivars for NSAccessibilityElement, including initializers and accessors.
Headers/AppKit/NSAccessibilityCustomRotor.h	Public ivars for rotor and item result classes.
Headers/AppKit/NSAccessibilityCustomAction.h	Declares new factory methods and perform method for custom actions.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] Setters for string attributes should copy (not just retain) to avoid surprises with mutable strings. Replace ASSIGN with ASSIGNCOPY here, and likewise in setAccessibilityIdentifier, setAccessibilityRole, and setAccessibilitySubrole.

[gcasa]

@copilot open a new pull request to apply changes based on this feedback

[gcasa]

I think this PR is ready as well, @fredkiefer / @rfm

[rfm]

I'm not familiar with what this stuff is supposed to be doing, but as far as I can see this replaces unimplemented code so can't really be breaking anything even if it doesn't operate correctly.

One thing that confuses me is the use of
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"

From what I read, that diagnostic should only be produced if you are building in ARC mode, but we don't make the core libraries depend on ARC and it doesn't look like you are even preparing to make this code depend on ARC (for instance, that would require the calls to [super dealloc]; to be replaced with the DEALLOC macro), so I wonder why the pragma to suppress a non-existent warning? Is it because a compiler bug generates an incorrect warning?

[fredkiefer]

I would prefer to see these few changes, but otherwise the code looks fine.

[gcasa]

This branch is not ready yet. I have so much more I didn't realize I have to do on this.

[Copilot]

@gcasa I've opened a new pull request, #398, to work on those changes. Once the pull request is ready, I'll request review from you.

[gcasa]

I'm not familiar with what this stuff is supposed to be doing, but as far as I can see this replaces unimplemented code so can't really be breaking anything even if it doesn't operate correctly.

One thing that confuses me is the use of #pragma clang diagnostic ignored "-Warc-performSelector-leaks"

From what I read, that diagnostic should only be produced if you are building in ARC mode, but we don't make the core libraries depend on ARC and it doesn't look like you are even preparing to make this code depend on ARC (for instance, that would require the calls to [super dealloc]; to be replaced with the DEALLOC macro), so I wonder why the pragma to suppress a non-existent warning? Is it because a compiler bug generates an incorrect warning?

I removed the code that supresses this warning as it was uneeded.