pub enum Cap {
Show 80 variants
DragDrop,
DragExternalImport,
DragExternalExport,
DragMultipleItems,
DragFileReferences,
DragDeferredReceipt,
DragFilePromises,
DragExternalMove,
ListRecycling,
UndoBridge,
EditBridge,
ListReorder,
NavReorder,
ListDelete,
ListSwipeActions,
ListEditing,
ListItem,
Tree,
TreeMove,
TreeSections,
BaselineAlignment,
TextRuns,
TextLinks,
Lottie,
NativeSymbols,
Snapshot,
NavSplit,
NavTabs,
NavTabsAdaptive,
NavRepresent,
NavContentList,
NavHeader,
Appearance,
AppMenu,
Dialogs,
FileDialogs,
Animation,
Cover,
CoverSheet,
StatusBarHidden,
TextEditable,
TextSelectable,
TextSpellCheck,
MultiWindow,
AppBadgeCount,
AppBadgeText,
AppBadgeDot,
Toolbar,
ToolbarSearch,
Inspector,
Split,
Cursor,
FontList,
ReduceMotion,
Announce,
ImageDecode,
ImageEncode,
ImageProperties,
CanvasBitmap,
CanvasPdf,
WindowStates,
WindowFullscreen,
ContentProtection,
WindowTabbing,
DockMenu,
WindowGeometry,
WindowPosition,
WindowLevel,
WindowAppearance,
RequestAttention,
FramelessWindow,
OverlayTitleBar,
TransparentWindow,
WindowMaterial,
DragRegion,
StatusItem,
AppProgress,
DockVisibility,
Monitors,
DynamicShortcuts,
}Variants§
DragDrop
Native data-transfer source and destination callbacks.
DragExternalImport
Transfers between independent native applications (inbound).
DragExternalExport
Transfers to independent native applications, including arbitrary binary MIME data.
DragMultipleItems
Lossless ordered items and alternatives between Day applications.
DragFileReferences
Existing native file references, distinct from promised/generated files.
DragDeferredReceipt
Native result can wait for asynchronous data receipt.
DragFilePromises
Generated files supplied to a destination after dropping.
DragExternalMove
External move acknowledgment safe for source deletion.
ListRecycling
UndoBridge
The toolkit fronts the app’s undo stack with the platform’s own undo system
(Toolkit::set_undo_state + Event::Undo): Native where one exists
(NSUndoManager on macOS/iOS, QUndoStack), Unsupported everywhere else, where
Day’s menu items and accelerators drive the stack directly and nothing platform-owned
needs mirroring (docs/model.md).
EditBridge
The toolkit routes the platform’s standard Cut/Copy/Paste to the app’s edit bridge
(Toolkit::set_edit_state + Event::Edit): the same menu items, shortcuts, and
responder precedence the platform’s text editing uses; a focused text widget keeps
its own clipboard behavior, everything else reaches the app (docs/menus.md).
Native where a system route exists (the responder chain, the browser’s clipboard
events), Emulated where Day’s own menu items dispatch it, Unsupported elsewhere.
ListReorder
The toolkit realizes ListProps::reorderable as drag-to-reorder rows: Native when the
platform’s own mechanism drives it (NSTableView drag/drop, UITableView drag delegates,
ItemTouchHelper, …), Emulated for a pointer-tracked fake (web-dom). Unsupported ⇒ the
list renders normally but rows cannot be dragged (docs/list.md).
Sidebar destinations can be reordered without sacrificing the toolkit’s navigation
presentation. Independent of ListReorder: UIKit supports draggable content lists
but retains its native navigation collection for sidebars.
ListDelete
The toolkit realizes ListProps::deletable as the platform’s delete gesture:
Native where the platform ships one (UIKit’s trailing swipe actions, Android’s
ItemTouchHelper, ArkUI’s ListItem.swipeAction), Unsupported on the desktop toolkits,
whose lists have no swipe idiom and where deletion belongs to a menu or a button
(docs/list.md).
ListSwipeActions
The toolkit realizes ListProps::swipe_actions as edge swipe actions: buttons
that reveal as the row tracks the swipe, with the far edge activating the first one
(docs/list.md). Native where the platform ships the affordance: macos-appkit
(NSTableView row actions, Mail’s own machinery) and ios-uikit
(UISwipeActionsConfiguration). Unsupported everywhere else: the affordance is
absent, and the app’s command lives in its explicit controls.
ListEditing
The toolkit realizes ListProps::editing as the platform’s list editing mode: rows
show their delete controls and reorder grips while the list is editing (docs/list.md).
Native on ios-uikit (UITableView editing). Unsupported everywhere else, where a
list has no separate editing mode: its rows already drag, swipe and open menus as they
are, and the list renders as if editing were off.
ListItem
The toolkit realizes kinds::LIST_ITEM as its own list row content (docs/list.md “List
items”): Native where the platform has a standard row it draws itself (UIKit’s
UIListContentConfiguration, a Material list item, AppKit’s image-and-text table cell,
a GTK row box), so the row takes the platform’s fonts, icon size, spacing, secondary
colors and check mark. Unsupported ⇒ the list_item piece composes the same content
from plain pieces. Apps have no reason to probe this; the piece does.
Tree
The toolkit realizes kinds::TREE as a hierarchical tree view (docs/tree.md):
Native where a platform tree widget hosts Day-built rows (NSOutlineView, the UIKit
sidebar list, GtkListView+TreeListModel, WinUI TreeView, ArkTS TreeView), Emulated
where Day flattens the tree onto its list machinery, Unsupported where neither
exists yet. An app gates its tree UI on this answer rather than showing a placeholder.
TreeMove
The toolkit realizes TreeProps::movable as drag-to-reparent/restack rows
(docs/tree.md). A strictly smaller set than Cap::Tree: a backend can render a
tree it cannot yet drag within.
TreeSections
Native two-level section headers; general trees may still be composed.
BaselineAlignment
The toolkit answers Toolkit::first_baseline, so rows can align text on its baseline
rather than on the middle of its box (docs/baseline.md). Native where the platform
reports the baseline itself (NSView.firstBaselineOffsetFromTop, View.getBaseline,
gtk_widget_measure), Emulated where Day derives it from the widget’s font metrics,
Unsupported ⇒ baseline-aligned rows fall back to centering and look exactly as they do
today.
TextRuns
The toolkit draws a label’s TextRuns: bold, italic, color or a monospace face within
one wrapping paragraph (docs/text-runs.md). Unsupported ⇒ the label renders its text
uniformly, which reads correctly and loses only the emphasis.
TextLinks
The toolkit makes a run carrying TextRun::link activatable, emitting
Event::LinkActivated. A strictly smaller set than Cap::TextRuns: several toolkits
draw a link run in link colors but have no way to hit-test it, and one (Android) can do
links or selection but not both (docs/text-runs.md).
Lottie
NativeSymbols
Snapshot
The toolkit can rasterize its window and hand back the pixels
(Toolkit::snapshot_window): what the dayscript screenshot step captures in-process
and what day::window_image() offers the app (docs/window-image.md). Unsupported where
a backend cannot draw itself into a bitmap: web-dom, which would need a rasterizer
shipped with it. Probe it before offering a “save a screenshot” affordance, rather than
offering one that fails when pressed.
The toolkit can present nav() as sidebar+detail split panes, a statement about the
toolkit, not about the window it is currently drawing. Whether a given host is split right
now follows from its SizeClass: the pieces layer resolves an automatic
props::NavPresentation against both, and re-resolves on every class change. A backend
with no split container answers Unsupported and stays stacked at every size.
The toolkit can draw a navigation host’s rows as its own chrome: a tab bar
(props::NavPresentation::Tabs) and, where it has one, a rail
(props::NavPresentation::Rail). Like Self::NavSplit this is a statement about the
toolkit, not about the window it is drawing right now.
This is what NavStyle::Automatic resolves against (docs/navigation.md): a backend
answering Unsupported gets the sidebar resolver instead (Split ↔ Stack), which is
what every backend did before adaptive navigation existed. So an unimplemented backend
degrades to its previous behavior rather than to a hole.
Emulated means the rows are composed from other widgets rather than drawn by a native
tab container (Qt, web-dom). Native means a real one (UITabBarController, a Material
NavigationBarView, NavigationView).
A narrow window should become a tab bar here, a separate question from Self::NavTabs,
which only says the toolkit can draw one.
The two differ on every desktop. macOS, GNOME, Qt and Windows can all draw a tab bar, and
must, because an app is free to pin NavStyle::Tabs; but none of them grows one when
its window is dragged narrow. A narrow Mail.app hides its sidebar and pushes; it does not
sprout a bottom tab bar, and an app that did would look like a port. The phones and the web
are the opposite: those are the surfaces whose window size ranges from a phone to a
desktop, and a tab bar is what their users expect at the narrow end.
So this is a statement about the platform’s idiom, not about its widget set:
Native/Emulated:NavStyle::Automaticmay resolve toprops::NavPresentation::Tabson a compact window (ios-uikit, android-mdc, harmony-arkui, web-dom).Unsupported: it may not; a compact window collapses toprops::NavPresentation::Stackinstead, exactly asNavStyle::Sidebarhas always done (macos-appkit, linux-gtk, linux-qt, windows-winui).
props::NavPresentation::Rail is not gated by this. A narrow sidebar is an ordinary
desktop shape (on Windows it is what NavigationView does at that width on its own), so
the rail rung stays available everywhere Cap::NavSplit is.
How a navigation host’s presentation follows the window (docs/size-classes.md). All three answers mean something different here, and the difference is who decides:
Native: Day tells the toolkit. The pieces layer resolves the presentation from theSizeClass, re-resolves on every change, and sendsprops::NavPatch::Presentation; the toolkit rebuilds its chrome and re-homes the pages it already has. The desktops and web-dom.Emulated: the toolkit tells Day. Its own adaptive container owns the decision (UISplitViewControllercollapsing as a Pro Max iPhone rotates,SlidingPaneLayoutmeasuring whether both panes fit), so Day must not push a presentation into it: that would be a second decision racing the platform’s own animation. The toolkit reports what it did withEvent::NavPresentationChangedand Day reconciles.Unsupported: nobody re-presents. The presentation is resolved once, fromCap::NavSplitalone, and the window’s size never enters into it. A toolkit that cannot change presentation must not have it decided by something that can, or a window launched narrow would be stuck stacked with no way back.
The toolkit places a navigation host’s content-list page (props::Pane::List) in its
own pane between the sidebar and the detail, the Mail shape: mailboxes, message list,
message (docs/navigation.md). The three answers differ on what happens when the host
leaves the split:
Native: the pane exists at every presentation. A narrow window collapses the sidebar but keeps the list beside the detail, exactly as a narrow Mail.app does (macos-appkit: acontentListNSSplitViewItem).Emulated: the pane exists while split and merges into the navigation stack when the host collapses (ios-uikit:UISplitViewControllertriple-column). The pieces layer then interposes the list between the sidebar root and the detail (props::NavPatch::ListInStack) and gates the detail push on the app’sdetail_visiblebinding.Unsupported: the backend never seesprops::Pane::Listorprops::NavProps::list_width; the nav piece composes the pane beside (split) or in place of (stacked) the destination content itself.
The toolkit shows the current destination’s title in a native header/bar, so a page
needn’t repeat it in its own content. Native on XAML (the NavigationView header),
UIKit (UINavigationBar), Android (MaterialToolbar), and ArkUI (NavDestination
title bars). The desktop custom back-headers (AppKit/Qt/web) show a title only in
stack mode, so those backends stay Unsupported (docs/navigation.md).
Appearance
The toolkit applies a runtime appearance override (set_appearance): native widgets
restyle in place and dark_mode answers the override. Probe before showing a theme
picker; on Unsupported backends the call is ignored.
AppMenu
The toolkit renders an application menu bar (docs/menus.md), so app_menu is visible to
the user, and register_preferences gets its automatic Settings… item.
The question an app asks before deciding where a command lives. Settings is the usual
case: on a platform with a menu bar it belongs in the App menu and putting it in the
navigation as well is clutter; on one without, the menu is a no-op and a Settings row is
the only way in. Distinct from Cap::Toolbar: web-dom draws a window toolbar and has no
menu bar at all, so keying off the toolbar strands Settings there.
Dialogs
The toolkit can present native alert/confirm/sheet/prompt modals (docs/dialogs.md).
FileDialogs
The toolkit can present native open/save file pickers (docs/files.md).
Animation
The toolkit runs backend-executed animation for AnimSpec intents on
update/set_frame/set_opacity/set_transform (§8.4). Unsupported ⇒ animated calls
apply instantly (still correct, just not animated).
Cover
The toolkit presents a kinds::COVER node as a native fullscreen modal surface
(docs/cover.md). Unsupported ⇒ the cover piece’s content never shows.
CoverSheet
The toolkit presents a .sheet() cover as a native modal sheet (AppKit’s window sheet,
UIKit’s page sheet) over the page it covers (docs/cover.md “Modal sheet”). Unsupported
⇒ the cover piece composes the sheet itself: on a window wider than compact, a card
centered over the dimmed page; on a compact one, the full window.
StatusBarHidden
The toolkit can hide the system status bar while a status_bar_hidden subtree is
mounted (Toolkit::set_status_bar_hidden, docs/cover.md). Native on the phone and
tablet backends; desktop and web have no status bar, so a setting that offers to hide
it should be offered only where this is not Unsupported.
TextEditable
The toolkit’s text_area can be made read-only (TextAreaProps::editable = false).
TextSelectable
The toolkit’s text_area selectability can be toggled (TextAreaProps::selectable).
Unsupported where selection is always on (GTK); Emulated where the backend
collapses native selections itself (XAML, ArkUI).
TextSpellCheck
The toolkit’s text_area has built-in spell-check/autocorrect (TextAreaProps::spellcheck).
Unsupported where the toolkit ships none (GTK, Qt, ArkUI).
MultiWindow
The toolkit can open additional native OS windows (Toolkit::open_window,
docs/windows.md). Native on the desktop backends and on mobile backends whose
platform has a real secondary-window surface (iPad scenes, Android document
activities, OHOS multiton abilities). On Unsupported backends
day_core::open_window still works; the content presents as a fullscreen cover in
the primary window instead. Probe it to adapt chrome: an Unsupported tier has no
native title bar or close button, so window content should carry its own close
affordance.
AppBadgeCount
The toolkit can put a count on the app icon (Toolkit::set_app_badge, docs/badge.md).
Emulated where the call is made but the shell may ignore it: desktop Linux, where the
Unity launcher protocol is honored by Plasma and Dash-to-Dock but not by stock GNOME.
AppBadgeText
The toolkit renders AppBadge::Text as written. macOS only: NSDockTile.badgeLabel is an
arbitrary string, while every other platform’s badge is a number or nothing.
AppBadgeDot
The toolkit can show a valueless indicator (AppBadge::Dot).
Toolbar
The toolkit gives a window chrome that persists across pages
(Toolkit::edit_toolbar, docs/toolbars.md): Native on the desktop backends and the
phones, Emulated on web-dom, Unsupported where the only chrome belongs to a page.
It no longer decides whether a command can be shown at all: a toolbar item declared on a piece rides that piece’s own chrome everywhere. Probe it only for a layout decision that turns on a persistent bar existing.
ToolbarSearch
The window toolbar can hold a search field (docs/search.md): Native on the desktop
backends, Emulated on web-dom. Unsupported on the phones, whose bar is a row of actions
(an Android app-bar menu, iOS bar buttons, ArkUI title-bar menus): their field goes on the
navigation surface instead, so SearchPlacement::Toolbar resolves to Inline there.
Inspector
The toolkit realizes kinds::INSPECTOR as its own trailing-pane container
(docs/inspector.md): an NSSplitView inspector pane, a GtkPaned with the panel as
its end child, a QDockWidget, a XAML SplitView right pane. Unsupported ⇒ the
inspector piece composes the pane from plain containers instead (same panel, same
signal, no native divider), so an unimplemented backend degrades to a drawn pane, not
to a hole. Apps normally have no reason to probe this; the piece does.
Split
The toolkit realizes kinds::SPLIT as its own splitter (docs/split.md): an
NSSplitView, a GtkPaned, a QSplitter, each side by side or stacked and with the
divider the user drags. Unsupported ⇒ the split piece composes the two panes and
draws and drags the divider itself (the web, the mobile toolkits, XAML), so the piece
behaves the same everywhere and only the divider’s look is the toolkit’s. Apps have no
reason to probe this; the piece does.
Cursor
The toolkit shapes the pointer over a node from the .cursor() decorator
(Toolkit::set_cursor, docs/cursor.md). Native where the platform draws the requested
shape from its own set (AppKit, GTK, the DOM, Android’s PointerIcon), Emulated where
some shapes map to a nearest neighbor (Qt, XAML) or the platform draws pointer effects
rather than shapes (iPadOS), Unsupported where nothing changes: a touch-only toolkit,
or one whose pointer API Day does not reach yet. Apps ask before offering an affordance
that only a cursor reveals, such as a resize handle with no other visual.
FontList
The toolkit can enumerate the platform’s font families with the faces each ships
(Toolkit::font_families, docs/fonts.md). Native where an OS font database answers
(NSFontManager, UIFont, Pango, QFontDatabase, Android’s fonts.xml,
OH_Drawing_FontMgr, DirectWrite); Emulated where the list is composed rather than
read: web-dom answers the CSS generic families plus the bundled document.fonts, since
a browser exposes no local font list without a permission prompt; Unsupported means
the list is empty and an app should offer only the default face. Measurement
(Toolkit::measure_text) has no probe: a None answer degrades to
TextMetrics::approximate. Probe this before offering a font menu, not before
drawing; a CanvasFont draws everywhere.
ReduceMotion
The toolkit reads the user’s reduce-motion setting (Toolkit::reduce_motion,
docs/accessibility.md) and reports when it changes. Native where the platform has the
switch and Day reaches it; Unsupported where Day reaches none (the app then animates as
it would with the setting off, and DAY_REDUCE_MOTION=1 still forces it on).
Announce
The toolkit can speak a sentence through the screen reader without moving its focus
(Toolkit::announce, docs/accessibility.md): “Saved”, “3 results”, “Upload failed”.
Native where the platform has an announcement request (NSAccessibility’s
announcement notification, UIAccessibility’s, Android’s accessibility event, GTK
4.14’s gtk_accessible_announce, a WinUI notification event); Emulated on the web,
where an ARIA live region carries it; Unsupported where Day reaches no announcement
API yet. An app with a visible status label needs no announcement: screen readers read
what changes on screen only when told to, so this is for the change the user cannot
otherwise learn about.
ImageDecode
The toolkit can turn encoded image bytes into a native image
(Toolkit::decode_image, docs/images.md): what image(bytes), a pasted screenshot and
a canvas image all rest on. Native wherever the platform decoder takes a buffer;
Unsupported means only staged asset names draw, so an app should not offer “open an
image” at all. Every backend that decodes also answers Toolkit::image_info, so pixel
size needs no probe of its own.
ImageEncode
The toolkit can encode a decoded image back to bytes (Toolkit::encode_image).
Which formats it encodes is Toolkit::encode_formats, the same shape as
Cap::FontList/Toolkit::font_families, because “can encode” and “can encode WebP”
are different questions and only the second one needs a list.
ImageProperties
The toolkit can read an image’s metadata beyond its pixels: EXIF orientation, DPI,
capture time (Toolkit::image_properties). Native where a platform metadata reader
is already linked (WinRT’s BitmapPropertiesView, Android’s ExifInterface);
Unsupported where reading it would mean shipping a parser or a new framework, which is
most places. An app that wants orientation must handle None.
CanvasBitmap
The toolkit can replay a canvas drawing into an offscreen bitmap
(Toolkit::render_bitmap, docs/canvas.md “Exporting”): what Drawing::to_bitmap and
Drawing::to_png rest on. Native where the toolkit’s own canvas painter can target an
image surface (a CGBitmapContext, a cairo image surface, a QImage, an android
Bitmap, an OH_Drawing_Bitmap, a detached <canvas>); Unsupported where the
on-screen canvas has no painter to retarget (WinUI builds XAML shapes instead).
CanvasPdf
The toolkit can replay canvas drawings into a PDF document (Toolkit::render_pdf,
docs/canvas.md “Exporting”), with vector shapes and the platform’s own font embedding.
Native only where the platform ships a PDF writer the canvas painter can draw into
(Core Graphics on AppKit and UIKit, cairo on GTK, QPdfWriter on Qt, PdfDocument on
Android); Unsupported on ArkUI, the web and WinUI, which have none.
WindowStates
The toolkit minimizes, zooms, hides and restores a window on request
(WindowChange::State, WindowChange::Visible, docs/windows.md) and reports what the
user does through Event::WindowStateChanged. Native on the desktop backends;
Unsupported on the phones and the web, whose windows the OS sizes.
WindowFullscreen
The toolkit takes a window fullscreen on request and reports when it enters and leaves
(WindowState::Fullscreen). Native on the desktops, on Android (system bars hidden
through WindowInsetsController), on HarmonyOS and on the web (the Fullscreen API, which
browsers allow only during a user gesture); Emulated on iOS, which hides the status bar
and lets the home indicator fade but always keeps the app full-screen anyway.
ContentProtection
The toolkit keeps a window out of screenshots, recordings and screen sharing
(WindowChange::ContentProtected). Native on macOS (NSWindowSharingNone), Windows
(WDA_EXCLUDEFROMCAPTURE), Android (FLAG_SECURE) and HarmonyOS (privacy mode);
Emulated on iOS, which has no switch for it: Day covers the content while the screen is
being recorded or mirrored, but a screenshot still captures it. Unsupported on Linux
and the web.
WindowTabbing
The toolkit honors WindowOptions::tabbing: macOS window tabs. Unsupported everywhere
else, where no system window tabs exist.
DockMenu
The toolkit shows a Dock menu (Toolkit::set_dock_menu, docs/menus.md): the app’s
shortcuts and dock_menu(..) entries above the system’s own items. macOS only.
WindowGeometry
The toolkit resizes a window and bounds its size on request (WindowChange::Frame’s
size, WindowChange::Limits, WindowChange::Resizable).
WindowPosition
The toolkit moves a window to a requested position (WindowChange::Frame’s origin).
Unsupported on GTK 4, which removed window positioning, and wherever the compositor owns
placement (Wayland).
WindowLevel
The toolkit changes how a window stacks (WindowChange::Level,
WindowChange::OnAllWorkspaces, WindowChange::SkipTaskbar).
WindowAppearance
The toolkit gives one window its own light/dark appearance (WindowChange::Appearance).
Where it cannot, the app-wide Toolkit::set_appearance still applies to every window.
RequestAttention
The toolkit asks for the user’s attention on request (WindowChange::RequestAttention):
a Dock bounce, a flashing taskbar button.
FramelessWindow
The toolkit opens a window with no title bar or frame (WindowChrome::Frameless,
docs/window-chrome.md). Desktop backends only.
OverlayTitleBar
The toolkit runs a window’s content under its title bar with the window controls kept
(WindowChrome::Overlay) and reports the bar’s height as the safe-area top inset.
TransparentWindow
The toolkit opens a window whose unpainted pixels show the desktop
(WindowBackground::Transparent).
WindowMaterial
The toolkit puts a translucent system material behind a window
(WindowBackground::Material): macOS’s visual-effect materials, Windows 11’s Mica and
Acrylic. Emulated where an approximation stands in.
DragRegion
The toolkit lets a piece move its window like a title bar does
(Toolkit::set_drag_region, .window_drag_region()). Emulated on the web, where
only an installed app with a window-controls overlay honors it.
StatusItem
The toolkit shows status items (Toolkit::set_status_items, docs/status-item.md): the
macOS menu bar, the Windows notification area, a Linux tray. On Linux the answer depends
on the desktop: Native while a StatusNotifierItem host is running (KDE Plasma, most
panels, GNOME with the AppIndicator extension), Unsupported without one (stock GNOME),
so an app can keep a window instead of vanishing into a tray nobody shows.
AppProgress
The toolkit shows progress on the app’s Dock or taskbar icon
(Toolkit::set_app_progress). Emulated on Linux, where the Unity launcher protocol is
honored by KDE Plasma and Dash to Dock but not by every dock.
DockVisibility
The toolkit can hide the app’s Dock icon while it runs (Toolkit::set_dock_visible).
macOS only.
Monitors
The toolkit lists the displays and their work areas (Toolkit::monitors). Emulated
where the one screen the app runs on is reported (a phone, the web).
DynamicShortcuts
The toolkit shows launcher shortcuts the app sets while it runs
(Toolkit::set_launcher_shortcuts).