API — ICoreEssentials/UI/Backends/WinUI/System

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

ICoreWinUIDragFields.h#

ICoreEssentials/UI/Backends/WinUI/System/ICoreWinUIDragFields.h

The DECISIONS half of the WinUI drag seat (W1.7 of the Windows UI plan).

⚠ NO WINDOWS TYPES AND NO WINRT TYPES IN THIS HEADER, which is the same split the event translation uses and for the same reason: a DataPackage can only be built inside a running App SDK, so everything that decides what goes INTO one is here, taking and returning plain values, and the half that touches the real object decides nothing and is proved by compiling.

WHAT IS ACTUALLY DIFFERENT BETWEEN THE TWO TOOLKITS. QMimeData is a bag keyed by MIME type and every entry goes in the same way. A DataPackage is not: text, storage items and application-private bytes each have their own setter, the standard ones are keyed by fixed ids that are not MIME types, and one of them cannot be filled synchronously at all.

ICoreWinUIDragPlan#

ICoreWinUIDragFields.h:33 · struct · 0 declaration(s)

What a caller must do to a DataPackage to carry one payload, and what it cannot carry.

struct ICoreWinUIDragPlan {
public:
    bool setText = false;
    ICoreString text;

    // SetData(customFormat, customData). The format id is passed through
    // unchanged: unlike the standard ids, an application-private one is an
    // arbitrary string on both toolkits, so the MIME name the tree already
    // uses works as-is.
    bool setCustom = false;
    ICoreString customFormat;
    std::string customData;

    // DataPackageOperation, as its integer -- Copy | Move, which is what the
    // Qt seat requests with CopyAction | MoveAction.
    unsigned int requestedOperation = 0;

    // Anything the payload asked for that a DataPackage cannot be given
    // synchronously, named. Empty is the normal case.
    std::vector<ICoreString> losses;
};
};

ICoreWinUIDropFields.h#

ICoreEssentials/UI/Backends/WinUI/System/ICoreWinUIDropFields.h

The INCOMING half of drag and drop, with no WinRT in it: what a DataPackageView yields as an ICoreMimePayload, and the sequencing rule that says which of enter / over / drop a target is allowed to see.

⚠ IT IS THE MIRROR OF System/ICoreWinUIDragFields.h AND DELIBERATELY THE SAME SHAPE. That file decides what goes INTO a DataPackage and reports what cannot go; this decides what comes OUT of one and which events follow. Both keep the decisions in a header a suite can drive with no App SDK, and both leave the seat holding nothing but the WinRT calls.

⚠ NOTHING ABOVE THE BACKEND ZONE MAY INCLUDE THIS.

ICoreWinUIDropAdvertised#

ICoreWinUIDropFields.h:30 · struct · 0 declaration(s)

What the package says it is carrying, already read out of it.

struct ICoreWinUIDropAdvertised {
public:
    bool hasText = false;
    ICoreString text;

    // Paths, already resolved from IStorageItem. The source side records that
    // it cannot SEND these synchronously and names the loss; receiving them has
    // no such problem, and its own comment says this is the one place in the
    // tree that writes `urls`.
    std::vector<ICoreString> urls;

    bool hasCustom = false;
    ICoreString customFormat;
    std::string customData;
};
};

ICoreWinUIDropState#

ICoreWinUIDropFields.h:91 · struct · 0 declaration(s)

-- the sequencing rule ------------------------------------------------------ ⚠⚠ A DRAG NOT ACCEPTED ON ENTER NEVER PRODUCES THE LATER TWO.

struct ICoreWinUIDropState {
public:
    // Whether the target accepted the ENTER. False until one is accepted, and
    // false again after a leave or a drop.
    bool active = false;
};
};

ICoreWinUIDropOutcome#

ICoreWinUIDropFields.h:98 · struct · 0 declaration(s)

What the seat must do with one incoming XAML event.

struct ICoreWinUIDropOutcome {
public:
    // Deliver to the target's hook. False means the seat swallows the event.
    bool deliver = false;

    // Set AcceptedOperation. When false the seat must set None, which is what
    // shows the "no" cursor.
    bool accept = false;

    // The operation to accept with, as its DataPackageOperation integer.
    unsigned int operation = 0;
};
};

ICoreWinUILiveness.h#

ICoreEssentials/UI/Backends/WinUI/System/ICoreWinUILiveness.h

IS THAT THING STILL ALIVE? The one liveness answer this backend has, wrapped once so the three weak-handle seats beside it do not each write a registry.

⚠ NOTHING ABOVE src/ICoreEssentials/UI/Backends/WinUI/ MAY INCLUDE THIS.

⚠⚠ IT IS A REGISTRY AND NOT A WEAK REFERENCE, AND THAT IS FORCED RATHER THAN PREFERRED. The GTK4 zone answers the same question with a GWeakRef and the AppKit zone with an ARC __weak, because on both backends the thing a handle points at is a TOOLKIT object with a runtime that nulls references for you. Here it is not: an ICoreWinUIWidgetElement is a plain C++ object living by value inside ICoreWidget::Impl, and an ICoreWinUISceneNode is a base subobject of an item's Impl. Neither has a control block, a retain count or a finalize hook for anything to hang a weak reference on. So liveness is a registry question here exactly as it is on AppKit, and this file is that

Declares no class of its own — see the file.

ICoreWinUIPlatformFields.h#

ICoreEssentials/UI/Backends/WinUI/System/ICoreWinUIPlatformFields.h

The DECISIONS behind the WinUI seat for UI/System/ICorePlatform.h. (The planning row this came from is named in the .cpp, not here -- see UI/Backends/WinUI/README.md.)

Peer of ICoreWinUIEventFields.h, ICoreWinUIDragFields.h, ICoreWinUIDropFields.h, ICoreWinUIRepaintFields.h and ICoreWinUIAccessibilityFields.h: nothing here decides where a key state came from, and everything that could be WRONG about reading one is here, so testingLabs/tests/winui_platform_hooks can reach it.

⚠ NO WINDOWS TYPES AND NO WinRT IN THIS HEADER, on the same rule ICoreWinUIEventMap.h states: every parameter is a plain integer or a bool, so the suite -- and anything else above the backend -- can include it without <windows.h> and without the Windows App SDK.

Declares no class of its own — see the file.

ICoreWinUIResourceBytes.h#

ICoreEssentials/UI/Backends/WinUI/System/ICoreWinUIResourceBytes.h

The zone's one answer to "a path in this tree could be a resource or a file".

⚠ THIS IS NOT A RESOLVER, AND THE DIFFERENCE MATTERS ENOUGH TO SAY. Backends/AppKit/System/ICoreAppKitResources.h turns ":/SVGs/x.svg" into a real path inside an .app bundle, because on that backend the bytes are a FILE. Here they are not: ICoreEmbeddedResources has been a byte array compiled into the binary since W9.5, so there is no path to resolve TO and a WinUIResources peer would be a second answer to a question that already has one. What this header holds is the READ, which is the only half this backend needs.

⚠ NOTHING ABOVE THE BACKEND ZONE MAY INCLUDE THIS.

⚠ IT EXISTS BECAUSE THE SAME EIGHT LINES WERE ABOUT TO BE WRITTEN TWICE IN

Declares no class of its own — see the file.