* Add craft-menu: Mac menu-bar layout and native-menu driver
A platform-free menu model (built directly or from flat rows), the macOS
layout (app menu, Window, Help, system-key clash resolution, translatable
labels), and NativeMenu, which feeds a backend's key equivalents to egui as
key presses, runs Minimize and craft-quit's Quit, and re-syncs only when the
app's state changes. Generalised from PhotoCraft's native_menu.rs.
* craft-menu: macOS menu bar through muda
* craft-menu: clipboard keys, layout-assigned shortcuts, Hide Others and atomic rebuilds
* craft-menu: menu key equivalents run while a text field has the keys
* craft-menu: commands as CommandRef, item kinds, craft-keymap chords
Items and rows run a craft_keymap::CommandRef and take a craft_keymap::Chord
shortcut; crates/menu/src/chord.rs is gone. Native ids are the command's key,
made unique with #2, #3 when a command is shown twice. Item.checked becomes
ItemKind { Plain, Check, Radio } (radio shows as a check item on macOS).
The built-in items' commands are Builtin::{Hide, HideOthers, Minimize, Quit}.
MenuRole gains Edit, View and Other; tag_submenu finds its menu by role.
While text editing, the keys left to the field are the clipboard keys and
craft_keymap::text_editing_chords. Adds the Platforms, Document and Gate types
(data only) and MenuBar::documents.
* craft-menu: Gate::allows, the one rule for what may run from the menus
* craft-menu: Windows, Linux and web layouts, documents in Window, keymap adapter
layout(bar, Target, options) dispatches to mac_layout, desktop_layout or
web_layout. Every layout drops what the target's Platforms leave out and lists
MenuBar::documents as radio items last in the Window menu (ItemRole::Document
is gone). Windows and Linux put About in Help, Settings in Edit as
Preferences and Quit in File (Exit on Windows); the web layout has no Quit and
takes the browser's own shortcuts off the items, reporting clashes. tidy drops
empty submenus.
apply_keymap sets shortcuts and toggle check items from a craft-keymap Keymap;
apply_state sets enabled and checked per frame.
* craft-menu: the egui-drawn menu bar for Windows, Linux and the web
* craft-menu: gate, command hook and one muda handler for the native menu
- NativeMenu::set_gate: app items greyed in place while modal or recording a
shortcut; take_clicks drops clicks the gate forbids when they are taken.
While recording, key equivalents reach egui as plain key presses.
- NativeMenu::on_command: a hook called from the menu event handler for each
allowed app click; take_clicks still returns every command.
- Dispatch, shared between the driver and the backend's handler
(Backend::attach replaces Backend::set_text_editing).
- Only Cmd or Ctrl chords become key equivalents; other shortcuts are not
shown natively (building an attributed title needs unsafe objc2 calls).
- mac: one muda event handler per process, routed to the latest install;
mac::install_app_menu ports craft-quit's minimal app menu onto it.
- craft_quit::install_app_menu is deprecated in favor of
craft_menu::mac::install_app_menu.
* craft-menu: the bar takes Target, README section and NOTICE credit
* craft-menu: bar tests beside the layout and native ones; only a click outside closes the menus
* craft-menu: clippy (complex types, Copy clones, elided lifetimes)
* craft-menu: keyboard access to the egui bar
A tap on Alt alone or F10 focuses the bar, Alt+letter opens a menu and
a letter in an open menu runs or opens the row with that mnemonic, as
in a Windows menu bar. Mnemonics are assigned per level from the shown
labels, underlined only while the keyboard drives the bar, and a label
without an ASCII letter shows its English letter after it ("文件(F)")
through the optional english hook. Preferred letters come from
MenuBarUi::mnemonics. A Mac target has none, and a dialog or the
shortcut recorder keeps the keys. Ported from PhotoCraft's menu_keys.rs
and menu_keys_tests.rs.
* craft-menu: one installer or the other; sort mnemonics before checking uniqueness
* craft-menu: egui 0.37
* craft-menu: text fields keep their Edit items; web names by the browser's system; sync per frame; stable check kinds; handled hook clicks
* craft-menu: sync reports a clash change on an unchanged bar
* docking: AppKit moves a native window for its bar drag on macOS
Moving a native window with OuterPosition every frame jitters on macOS:
the window's reported place and the pointer events disagree about where
the window is. On macOS the bar press (or the start of a drag of a
window's only tab or group) now sends ViewportCommand::StartDrag, which
winit turns into performWindowDragWithEvent, and the dock area sends no
OuterPosition for that drag.
egui keeps running frames during the move, but the window's reported
place lags it, so each frame takes the window's place as AppKit's
cursor (NSEvent::mouseLocation) less the pressed point. Drop targets,
the drag fade, cross-window routing and the drop use that point. The
drag ends on the first frame where NSEvent::pressedMouseButtons or egui
reports the release, and is resolved once; a desktop drop records
cursor less grab. Ctrl/Cmd is read from AppKit's modifier flags, since
AppKit sends no key events during the move, and Escape does not cancel
the move. A press released within the click distance docks nothing.
Windows, X11 and Wayland keep their paths.
The window system seam (WindowSystem, formerly DesktopCursor) tells the
cursor, the button, the modifiers and whether it moves windows.
NativeHost models AppKit's move (moves_windows, held): the window
follows the cursor at the grab and reports its place late. The
app-driven cursor path from #325 and its stale-pointer model are
removed, since macOS no longer takes that path.
* docs: a cancel during an AppKit bar drag leaves the window moving
The close button was a ✕ (U+2715) text glyph and the version pill used →, neither of which the bundled faces are guaranteed to have; apps that panic on a missing glyph took the whole prompt down. The close mark is two painted strokes, the pill reads 'v0.1.0 to 0.2.0', and a test asserts the prompt paints only ASCII text.
Fixes#343
A group dragged to the window edge where an iconic column sits showed the
edge line and an outline around the column. The edge line is drawn just
inside the window, so it lay in the column's body, and paint_drop_line
outlines the iconic column a line lies in. That outline is for drops into
the column; a window-edge drop docks beside it, so it now shows the line
alone.
A user can dismiss the prompt while the update installs and then edit. The close request is now kept until the app can close, so a close the user cancels is asked again once the work is saved. The installed message is set when the install finishes.
The restart helper is scheduled before the app closes, so a close the user then cancels would leave it waiting for an exit that never comes. Apps pass whether it is safe to start.
windows_precheck now refuses an executable that isn't the app's own, as the helper does, so the error is shown while the app can still show it. check_helper keeps the same check as the final guard.
check_helper accepted any existing file as a standalone install, so a differently named executable passed (the Windows test caught it). The program's name must be one of the app's own.
Local AppData comes from the known-folder API (a redirected profile is honoured), with the environment variable as the fallback. Once an update is installed and waits for the app to exit, no check, offer or install starts, so a cancelled close cannot relaunch the app twice.
* docking: menu key equivalents reach the focused text field of a native window
On macOS the menu bar takes key equivalents such as Cmd+C and Cmd+V before
the key window sees them, and an app's menu glue reports them in the main
window's input, where they ran on the document even while a text field in a
floating panel's own window had focus. Each native window notes its text
focus as it draws. While the window with the keyboard has a focused field,
the main window's input hands that window the keys a text field acts on
(Cmd+C/X/V/A, Cmd+Z and Shift+Cmd+Z, Cmd with the arrows, Cmd+Backspace and
Cmd+Delete, and Copy, Cut and Paste events); Cmd+C and Cmd+X arrive as Copy
and Cut, and Cmd+V asks the window for the clipboard text. Other command
keys stay with the main window, and nothing moves while input is blocked.
typing_window and send_keys expose the same routing to menus that run
commands themselves.
* docking: typing_window answers between frames with the last frame's focus
* docking: a dragged native window fades only while a drop target is highlighted
The dragged window stays opaque over empty space and goes to 75% only
while the bar, only-tab or only-tab-row drag shows a drop preview.
paint_group_drag reports whether it highlighted a target; end_cross keeps
that for the next frame, since the dragged window sets its opacity before
the preview is drawn.
* docking: a dragged in-window floating window fades only while a drop target is highlighted
The rule for native windows covers in-window floating windows too. A
title bar drag draws its window at DRAG_OPACITY (75%) while the drag
highlights a drop target, and opaque over empty space and after a drop,
Escape or focus loss. finish_group_drag keeps paint_group_drag's result
for the next frame, since the window draws before the preview.
FloatingFrame takes an opacity for the whole frame, contents included.
* docking: a title-bar drag also fades over a preview the host draws
* docking: keep native palettes shown while the app is inactive
Palettes no longer hide when none of the application's windows has focus.
They drop to WindowLevel::Normal while the application is inactive, so
they do not cover other applications, and go back to AlwaysOnTop when it
is active again. Files dragged from another application reach them, OS
sheets attached to them stay open, and they stay shown, dimmed, while an
app modal blocks input.
* docking: on Windows an inactive app's palettes go behind other windows
* docking: the viewer level test expects the inactive palette level
One tested implementation of what each app had copied: results are picked up even after the prompt is dismissed, a dropped or panicking worker is an error, the UI is repainted while work runs, a failed install returns to the prompt with its reason, and success asks the app to close through its own close path instead of exiting the process.
AppKit reports a native window's new place as soon as a move is
commanded, but measures the pointer events it sends against where the
window server had the window, which can be a move behind. Placing the
window from those events made it overshoot and step back while the
cursor moved smoothly.
On macOS the window now goes to NSEvent::mouseLocation, flipped against
the primary screen's height and divided by egui's zoom factor, less the
pressed point; drop targets are hit at the same point. Other platforms
keep placing the window from the frame's pointer move.
The cursor source is a DesktopCursor the test harness fixes. NativeHost
can tell the cursor (tells_cursor) and measure a window's pointer events
against its place some frames back (stale), through window_pointer.
A group bar drag to a dock band named by one of the moving panels, such as the window edge of the column the group heads, anchors on another panel of that column, as a tab drag does; with none, the drop is a no-op. Before, the model rejected the move and the drop did nothing.
Drops on the bands along the layout's outer edge (a new dock, a new outermost column, the outer edge band) preview the line along that edge instead of the rect the panels take; drops beside groups keep the rect. The window-edge column line sits inside the window, like the new-dock line.
With new_dock_zones (and without side_edge_zones), the body of a frame or
floating group that takes no tabs is no drop target, whatever its
accepts_splits. A floating window released there stays floating and a
docked panel floats as over empty space; the outer edge band, dock columns,
new docks and drops beside other groups still dock. Without new_dock_zones
the whole canvas body still goes to the nearest of drop_edges.
* docking: a minimized native window shrinks to its bar
A floating window shown in its own OS window kept its full size when
minimized, with an empty body under the tab strip. Minimizing now sizes
the OS window to its bar and the tab strip of its only group, at the
same width and top-left corner, and fixes its height with the window's
min and max inner size; expanding restores the saved size. The layout's
native and in-window rects keep the expanded height: the collapsed
height the window reports is not recorded, its position and width are.
* docking: a minimized native window's limits change before its size, and follow its bar height
dirs pulls in option-ext (MPL-2.0), which the apps' cargo-deny licence policy rejects, and zip 8.6 carries RUSTSEC-2026-0367, -0368 and -0369. The per-user folders now come from the environment.
aiongg
aiongg
skylar taylor-barrick
Dylan M. Taylor