API — ICoreEssentials/UI/Backends/AppKit/Values

The public contract of 5 header(s) under ICoreEssentials/UI/Backends/AppKit/Values — 0 class/struct definition(s), 0 declaration(s). Each section shows the header's banner and its public (and protected-virtual) surface exactly as the file writes it.

ICoreAppKitDiagonalCursor.h#

ICoreEssentials/UI/Backends/AppKit/Values/ICoreAppKitDiagonalCursor.h

The two DIAGONAL resize cursors, drawn, because macOS publishes neither.

⚠⚠ THIS EXISTS BECAUSE "NO PUBLIC PEER" WAS BEING READ AS "NO CURSOR", AND THE FOUR SHAPES THAT NEEDED IT ARE THE FOUR CORNERS OF EVERY RESIZE HANDLE IN THE EDITOR. Both cursor maps on this seat (Values/ICoreAppKitCursor.mm's forShape and Widgets/ICoreAppKitView.mm's toNSCursor) answered SizeForwardDiagonal and SizeBackwardDiagonal with [NSCursor arrowCursor], each with a note saying the real ones are private API (_windowResizeNorthWestSouthEastCursor and its twin). That is true, and it is not the end of the question: an NSCursor is an image and a hot spot, and AppKit will make one out of any image you hand it.

⚠ THE IMAGE IS THE SYSTEM'S OWN, ROTATED, RATHER THAN A SHAPE DRAWN FROM SCRATCH. [NSCursor resizeLeftRightCursor].image is the horizontal

Declares no class of its own — see the file.

ICoreAppKitKeyChord.h#

ICoreEssentials/UI/Backends/AppKit/Values/ICoreAppKitKeyChord.h

The AppKit backend's shortcut-chord encoding, and the peer of Events/ICoreAppKitEventMap.h. (The planning row is named in the .mm, not here -- the docs generator lifts header comments into public pages.)

NO OBJECTIVE-C AND NO TOOLKIT NAME IN THIS HEADER. Every value is a plain integer, so the verify test and the menu/shortcut code above the backend can include it without dragging AppKit in. The .mm is where CoreFoundation is named.

⚠ THE ENCODING IS Qt's COMBINED VALUE, DELIBERATELY. A chord is one std::uint32_t holding key | modifiers, with the key in the low 25 bits and the modifier flags in the top 7 -- exactly what QKeyCombination::toCombined() produces, and exactly the numbering ICoreKey/ICoreKeyModifier are already pinned to (ICoreInputEnums.h). Choosing a private numbering here would have

Declares no class of its own — see the file.

ICoreAppKitKeySequenceAccess.h#

ICoreEssentials/UI/Backends/AppKit/Values/ICoreAppKitKeySequenceAccess.h

IMPLEMENTATION SIDE ONLY, and the peer of ICoreNativeHandleAccess.h: the one sanctioned way to read the chords out of an ICoreKeySequence on this backend.

WHY IT EXISTS. The wrapper's public seam is nativeStorage(), a const void* deliberately saying nothing about what is behind it. On the Qt backend that is a QKeySequence and icoreQt() casts it; here it is two packed 32-bit chords, and the struct describing them is private to ICoreAppKitKeySequence.mm so that ONE file owns the layout. Menu and shortcut code needs those chords. Reaching into the storage at each call site would put the layout in three places and make the next change to it a silent miscompile rather than a link error.

NO OBJECTIVE-C AND NO TOOLKIT NAME HERE -- the chords are plain integers, so the verify tests include this without dragging AppKit in.

Declares no class of its own — see the file.

ICoreAppKitPixmapAccess.h#

ICoreEssentials/UI/Backends/AppKit/Values/ICoreAppKitPixmapAccess.h

Reaching into an ICorePixmap's raster from inside the AppKit zone. (The planning row is named in the .mm, not here.)

This is the peer of the Qt backend's icoreQt(const ICorePixmap&): the seam exists because a raster is only useful when something can draw it or draw INTO it, and the public header deliberately hands out nothing but a void*. Both callers are inside this zone -- the painter that blits a pixmap, and the pixmap painter that targets one.

NO OBJECTIVE-C HERE, only CoreGraphics C types, so a verify test can include it without AppKit.

Declares no class of its own — see the file.

ICoreAppKitThemeAppearance.h#

ICoreEssentials/UI/Backends/AppKit/Values/ICoreAppKitThemeAppearance.h

⚠⚠ THE APPLICATION'S THEME AND THE MACHINE'S APPEARANCE ARE TWO DIFFERENT SETTINGS, AND EVERY NATIVE CONTROL IN THIS TREE OBEYS THE WRONG ONE.

This product picks its own theme -- ICoreThemeManager's "Light"/"Dark" -- and paints almost everything itself from those tokens. What it does NOT paint is the handful of parts AppKit still draws inside a native control: an NSOutlineView's disclosure triangle, an NSTableHeaderView's ground and its caption. Those are drawn from SEMANTIC colours, which resolve against the view's NSAppearance, which by default is the system's.

So on a Mac set to Dark running this app's light theme, an outline view's expand arrows came out WHITE on a white ground and its column captions came out white on a light header: invisible, with no colour named anywhere in this tree that a reader could go and change.

Declares no class of its own — see the file.