API — ICoreEssentials/UI/Backends/AppKit/System

The public contract of 4 header(s) under ICoreEssentials/UI/Backends/AppKit/System — 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.

ICoreAppKitPasteboard.h#

ICoreEssentials/UI/Backends/AppKit/System/ICoreAppKitPasteboard.h

ICoreMimePayload <-> NSPasteboard, in one place. (The planning row is named in the .mm, not here: a published header's comments are published.)

This is the piece BOTH sides of interchange need: the drag source writes a payload onto a dragging pasteboard, and a drop reads one back off it. The Qt backend never needed a file like this because QMimeData IS the payload in all but name -- mime->setText, mime->setUrls, mime->setData map one to one, and ICoreEventConversion.h's fromMime() reads them back. AppKit has no single object holding many representations, so the mapping has to be written down, and it is written down HERE rather than inside the drag seat, because a drop handler needs the reading half without wanting the drag loop.

NO OBJECTIVE-C IN THIS HEADER -- the convention every header in this zone follows (ICoreAppKitView.h, ICoreAppKitPixmapAccess.h). The pasteboard

Declares no class of its own — see the file.

ICoreAppKitPasteboardTypes.h#

ICoreEssentials/UI/Backends/AppKit/System/ICoreAppKitPasteboardTypes.h

The pasteboard TYPE NAMES this backend interchanges under -- and nothing else. (The planning row is named in the .mm, not here.)

⚠ THIS IS A SEPARATE FILE FROM ICoreAppKitPasteboard.h FOR ONE MEASURED REASON, AND IT IS NOT TIDINESS. That header declares functions taking and returning an ICoreMimePayload, which reaches ICoreString.h, which includes <QAnyStringView>. Anything that includes it therefore needs Qt on the include path, QtNetwork among the frameworks and ICoreString.cpp linked (§0.17 trap 5) -- and the one caller that needs the type NAMES is the view base's drop registration, whose whole header is deliberately buildable with a bare clang++ -I src. Eleven lab recipes compile that file that way.

So the names, which are pure AppKit strings with no payload type anywhere near them, live here, and the two files that need them -- the bridge that

Declares no class of its own — see the file.

ICoreAppKitPasteboardWriting.h#

ICoreEssentials/UI/Backends/AppKit/System/ICoreAppKitPasteboardWriting.h

One payload, rendered as the pasteboard OBJECTS that carry it (Apple backend, A1.7). This is the half of the bridge that both a clipboard write and a DRAG need, and until the drag crashed it existed only inside icoreAppKitWritePayload().

⚠ A THIRD HEADER IN THIS PAIR, AND THE REASON IS THE SAME ONE THAT SPLIT THE SECOND. ICoreAppKitPasteboard.h says "NO OBJECTIVE-C IN THIS HEADER" so that a C++ TU can drive the bridge without importing AppKit, and ICoreAppKitPasteboardTypes.h holds the type NAMES so that the view base can learn them without dragging Qt in through ICoreMimePayload. This declaration can satisfy neither rule -- it names an ObjC protocol AND a payload -- so it sits in its own file rather than weakening one of theirs. Its only two includers are the bridge that implements it and the drag seat that needs it, and both already import AppKit and know the payload.

Declares no class of its own — see the file.

ICoreAppKitResources.h#

ICoreEssentials/UI/Backends/AppKit/System/ICoreAppKitResources.h

Where a ":/..." path resolves to on this backend.

THE PROBLEM THIS EXISTS FOR, AND WHY IT IS NOT A "Values/" DECISION MADE TWICE.

The other toolkit compiles a resource blob INTO the binary from .qrc files and answers ":/SVGs/HomeIcon.svg" out of it. There is no such blob in an appkit build. ICoreAppKitPixmap.mm records the consequence honestly -- a ":/..." path "loads nothing here, and it returns a null pixmap rather than pretending" -- and defers the seam, because inventing one from a value type would be one backend's private guess.

Icons are where deferring stops being possible: 299 ":/..." spellings exist tree-wide and three .qrc registries feed them, so on this backend the whole

Declares no class of its own — see the file.