The launcher lets someone keep an app on an older release or on nightlies,
but the app's own update check never knew, so a pinned app prompted to
update on every start and "Update and restart" undid the downgrade.
`pins` is one small file the launcher writes (versions.json in its per-user
data folder, or the absolute path in CRAFT_VERSIONS_FILE) and apps read:
app id to Stable, Nightly or Pinned(tag), the launcher's own serde shape.
A missing or damaged file means everyone follows stable; an entry a newer
launcher wrote is left to the launcher and kept on save.
`Updater` reads it before each check and before an offer. An app kept off
stable gets no prompt and no network call; a requested check reports
UpToDate, and `Updater::managed()` says why, so the public Status enum is
unchanged and no app breaks on a rev bump.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The update prompt drew the app name's first letter in a blue square and used that blue for
its buttons and highlights. App gains accent and developer, and the prompt now draws:
- App::icon_png (decoded once per context, PNG only, at most 1024 px a side and never past
the renderer's texture limit), keeping the letter badge for an app without a usable icon;
- App::accent filling its buttons, the badge and an UPDATE chip, with white or black text,
whichever contrasts more, so every Craft app's accent reaches WCAG AA (4.5:1) for these
small labels; the What's new link is body text with an accent underline (accent-coloured
text missed 4.5:1 for several apps). No accent keeps the default blue;
- "by <developer>" beside the app name: App::developer, ArtCraft (app::DEVELOPER) for every
app in the storytold organisation unless the app passes its own;
- its own button states: backgrounds for unfilled buttons (LATER, DISMISS) when hovered and
pressed, as the host app's style can hover in a colour its dark text doesn't read on, and a
2 px focus ring in the body text colour on every button (egui shows focus in that state)
and on the What's new link.
Apps opt in by passing their own App, e.g.
App { icon_png: Some(include_bytes!("…128x128…png")), accent: Some([0x3f, 0x5f, 0xe0]), ..suite::WORDCRAFT }.
* craft-print: log why the printer list is empty when lpstat can't run; document Flatpak needs
Flatpak apps saw "No printers found" with working CUPS printers: the Freedesktop
runtime has libcups but not lpstat/lp, and the sandbox had neither the CUPS socket
nor Avahi (driverless printers come from lpstat -e). Log the spawn failure and say
in the README what a Flatpak must bundle and grant.
* craft-print: log a failed lpstat -p -d; README separates what each Flatpak piece is for
Review (CodeRabbit): a non-zero lpstat exit was dropped silently, and the README
said any missing piece empties the printer list when only lpstat and the socket do.
* craft-print README: driver options need the PPD, remote servers need network, socket paths are remapped
Review (CodeRabbit): printer_options reads /etc/cups/ppd before lpoptions, so it is
the PPD, not lpoptions, that a Flatpak lacks; a client.conf server is reached only
with --share=network.
* craft-print README: scope the CUPS_SERVER override to one app; describe the stricter socket wrapper
Review (CodeRabbit): flatpak override without an app id applies to every app.
* craft-update: a Windows MSI copy updates itself in its own context, wherever it is installed
Self-update only recognised an MSI copy by the launcher's per-user folder (the HKCU InstallDir
key, or %LOCALAPPDATA%\Programs\<App>). Every app installed for everyone, in
Program Files\ArtCraft\<App> or the older Program Files\<App>, was treated as a loose folder and
updated by unpacking the portable zip over Program Files without permission.
- msi_context moves here from the launcher (craft-launcher crates/native/src/msi_context.rs at
b827fed, unchanged apart from visibility, MsiScope and scope_arguments). Windows Installer's
own registration decides a copy's context, for the launcher and the apps alike, so the
launcher can drop its copy and both routes follow one rule.
- New msi_copy module: a copy is an MSI copy when an App Paths entry names its exe (a registry
read, cheap enough for status checks). Its update asks Windows Installer for the context; the
App Paths hive is only the fallback when that lookup cannot run.
- The update stops, before the app exits, when the copy is registered in both hives, the lookup
is unclear, or Windows lists the app more than once.
- After the update the helper starts the exe the registrations name now, since the package may
have moved an exact old default folder.
- A failed self-update now names the Windows Installer log, as the launcher's installs do.
- The launcher's own per-user package is recognised and updated exactly as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* craft-update: a copy only takes the Windows Installer context of its own hive
Review follow-up (CodeRabbit on #419). The product code for the context lookup came from the
app's only uninstall record, which was not proven to own the running exe. A package writes App
Paths under HKMU, always the hive of its own context, so a registration whose Windows Installer
context differs from the hive that named this exe belongs to another copy. The update now stops
then, instead of taking the other copy's context.
Also documents the remaining helpers the diff touches.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* craft-update: an app in the old per-user folder is judged by its registration first
Review follow-up (CodeRabbit on #419). The folder rule for the launcher's per-user package also
matched an app installed in %LOCALAPPDATA%\Programs\<App>, and it ran before the App Paths
check, so such a copy skipped the product-count, conflict and context checks. Now an app is
judged by its registration first; the folder rule only covers an app copy no registration names.
The launcher in its own folder still keeps its old path whatever is registered: on a real PC it
has an App Paths entry and a stale second uninstall record, and registration-first would have
stopped its self-update.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* craft-update: when the Windows Installer lookup cannot run, the uninstall records decide
Review follow-up (CodeRabbit on #419). The fallback trusted the App Paths hive, so a stale entry
or a product registered in both scopes could run the update in the wrong context. The fallback
now follows the launcher's rule: the context every uninstall record of the product agrees on
(msi_context::single_scope over HKLM in both views and HKCU). Missing or mixed records stop the
update, and an agreed context that differs from the App Paths hive still stops it as another
copy's registration.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Review follow-up (CodeRabbit on #423). If LOCALAPPDATA\Programs or Programs\ArtCraft is itself a
junction, the exe's folder resolves through it but a default path built from a resolved
LOCALAPPDATA does not, so a default install was planned as a chosen folder. The Windows layer now
resolves each complete default folder (new default_folders) and hands them to the planner, which
only compares.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review follow-up (CodeRabbit and CI on #423):
- The profile roots and LOCALAPPDATA are canonicalised like the exe's folder, so a profile behind
a junction or a subst drive still matches its default folder and still counts as the profile.
- When a failed move leaves no program to start, the helper starts nothing, so the recorded
"run its installer" message is not replaced by a restart error.
- The default-folder test builds its expected path the way the plan does, so it also passes
where Path::join uses '/' (Linux CI).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reported by FredApps: PhotoCraft built from main as 0.17.0-integration.20261029.f5b3f123 offered
"Update and Restart" to 0.17.0, a downgrade. Semver puts a pre-release before its release, and
the update check and the self-update guard compared with plain semver.
New version::offers_update: a pre-release label the suite publishes (alpha, beta, rc, nightly)
sorts as before; any other label marks a build from source, which is only offered a strictly
higher X.Y.Z. check_for_update (through a new testable offered_release) and the self-update
guard both use it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Temporary (craft-libs#422, step 4): new msi_migrate module, to be removed two releases after the
app packages become per-machine only.
The released packages refuse a per-machine install while a per-user copy exists, so the move
removes first and installs second: remove the per-user product (no permission prompt; if that
fails nothing has changed), install the new version for everyone, and if that fails or
permission is refused, install the new version for the account again in its old folder.
Settings and documents live outside the program folder and are never touched.
Which copies move: a per-user default folder goes to Program Files\ArtCraft\<App>; a chosen
folder outside the profile moves in place; a chosen folder inside the profile keeps updating
for the account. The launcher's own package never moves.
Tested with real Windows Installer runs of a renamed dual-scope package carrying the apps' own
install-policy.wxi: the move with the permission prompt accepted (twice), and with it refused
(the app came back for the account at the new version, the failed log kept). Also unit tests for
every plan and the order of steps, and a mutation check (9 of 9 killed).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review follow-up (CodeRabbit on #419). The fallback trusted the App Paths hive, so a stale entry
or a product registered in both scopes could run the update in the wrong context. The fallback
now follows the launcher's rule: the context every uninstall record of the product agrees on
(msi_context::single_scope over HKLM in both views and HKCU). Missing or mixed records stop the
update, and an agreed context that differs from the App Paths hive still stops it as another
copy's registration.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review follow-up (CodeRabbit on #419). The folder rule for the launcher's per-user package also
matched an app installed in %LOCALAPPDATA%\Programs\<App>, and it ran before the App Paths
check, so such a copy skipped the product-count, conflict and context checks. Now an app is
judged by its registration first; the folder rule only covers an app copy no registration names.
The launcher in its own folder still keeps its old path whatever is registered: on a real PC it
has an App Paths entry and a stale second uninstall record, and registration-first would have
stopped its self-update.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review follow-up (CodeRabbit on #419). The product code for the context lookup came from the
app's only uninstall record, which was not proven to own the running exe. A package writes App
Paths under HKMU, always the hive of its own context, so a registration whose Windows Installer
context differs from the hive that named this exe belongs to another copy. The update now stops
then, instead of taking the other copy's context.
Also documents the remaining helpers the diff touches.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Self-update only recognised an MSI copy by the launcher's per-user folder (the HKCU InstallDir
key, or %LOCALAPPDATA%\Programs\<App>). Every app installed for everyone, in
Program Files\ArtCraft\<App> or the older Program Files\<App>, was treated as a loose folder and
updated by unpacking the portable zip over Program Files without permission.
- msi_context moves here from the launcher (craft-launcher crates/native/src/msi_context.rs at
b827fed, unchanged apart from visibility, MsiScope and scope_arguments). Windows Installer's
own registration decides a copy's context, for the launcher and the apps alike, so the
launcher can drop its copy and both routes follow one rule.
- New msi_copy module: a copy is an MSI copy when an App Paths entry names its exe (a registry
read, cheap enough for status checks). Its update asks Windows Installer for the context; the
App Paths hive is only the fallback when that lookup cannot run.
- The update stops, before the app exits, when the copy is registered in both hives, the lookup
is unclear, or Windows lists the app more than once.
- After the update the helper starts the exe the registrations name now, since the package may
have moved an exact old default folder.
- A failed self-update now names the Windows Installer log, as the launcher's installs do.
- The launcher's own per-user package is recognised and updated exactly as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Add craft-dialogs: native file and message dialogs that never block the event loop
Requests queue and show at the end of the frame on the main thread; answers come
back with the app's continuation on a later frame. One dialog at a time, a drop
guard and a panic guard so a dialog never stays open, and an override for tests.
On macOS, Open and Folder show as a free-standing NSOpenPanel
(beginWithCompletionHandler, which rfd can't show), Save and message boxes as
sheets through rfd's async dialogs, never falling back to runModal. Filter
extensions match in any letter case on Linux.
* craft-dialogs: Dialogs::raise brings the open macOS panel to the front
* CI: dialogs workflow (Linux clippy and tests for craft-dialogs)
* craft-dialogs: per-instance macOS panel, parent window check, override panic guard, CI lints macOS code
* craft-dialogs: raise only a visible panel; Open and Folder need a running app
* ci: window and ui run macOS only when started by hand
macOS runners are kept for releases. Pushes and pull requests run Linux and Windows; workflow_dispatch runs all three.
* ci: the other workflows run macOS only when started by hand
atomic, docpath, ai-core, i18n, print, pdf, update and keymap follow window and ui: Linux and Windows on pushes and pull requests (keymap: Windows), all their platforms on workflow_dispatch.
* craft-ui: combo boxes whose menu grows back with its contents
egui's ComboBox lays its menu out in the height it had on the previous pass,
and its scroll area takes no more than that. A filtered list that shrinks (a
search with no matches) never grows back when the search is cleared
(emilk/egui#5225, #5138). craft_ui::combo::menu offers its contents the full
height on every pass; craft_ui::combo::combo draws the combo box button
around it. The Font Manager's Language, Script and Sample menus use it.
* craft-ui: combo and menu take the close behaviour
A menu with a search field that closes itself on a pick (DesignCraft's font
menu) closes on a click outside only.
* craft-ui: ComboBox, a drop-in for egui's combo box, with header menus
craft_ui::ComboBox has egui 0.37's ComboBox builder and button (same
atoms, style classes and icon, pixel-identical in a test) with a menu that
grows back. show_ui_with_header and show_rows_with_header keep a search
field in place and scroll only the list; combo::Menu is the same menu under
a field an app draws itself. clippy.toml disallows egui::ComboBox.
The Font Manager's Language menu, the keymap dialog's combo boxes and the
print dialog's printer and duplex choices use it.
* craft-ui: combo menus keep to the room on their side, and footers
A menu is never taller than the room on the side of its field it opens on,
so an unbounded height fits on screen and scrolls. The side is settled once
the menu is measured and kept while it is open, so a menu that shrinks or
grows while typing doesn't jump to the other side of its field.
Footer forms keep a row under the scrolling list. Menu::new takes the
field's Ui for its default height and frame, and Menu::open shows the menu
under a text field that keeps the focus while typing.
* craft-ui: combo menus open by the app keep their side, and take picks
Menu::open takes &mut bool: the menu clears it when it closes (close
behavior, Escape, ui.close(), the field losing the focus to anything but
the menu), so a click on a row under a focused text field is picked.
The side settles only once the menu was shown and measured, also for
menus the app opens (Popup::open_id). A footer that changes height
remeasures the menu before it is shown. The popup frame's margins come
from the popup style; only above/below alignments are tried.
* craft-ui: a resting pointer over a combo menu doesn't keep it open
The menu counts the pointer as having moved into it only on a press or
click. A footer height change also requests a repaint, in case the
discard is denied.
* craft-ui: a footer menu opens without a second sizing pass
A footer height change no longer discards the pass or forces another
sizing pass: the menu measures again on the next pass and settles its
side then. A forced sizing pass ran a search field's focus request in a
pass where the field can't take the focus, so a footer menu opened with
the search unfocused.
* craft-ui: tests use Ui::scope_id
* craft-ui: hide the measuring pass of a footer menu, cap remeasures
The pass that measures a menu before its side is settled is laid out but
drawn fully transparent, so no frame shows a side or height the menu then
leaves. A footer that changes height on every pass remeasures twice per
open, then settles.
* craft-ui: tests satisfy clippy
Assign in the detail pane adds the recorded chord to the command and takes
it from the commands listed under "Currently assigned to", as one undo
step, without opening the conflict bar. ConflictMode::Keep keeps both.
A chord recorded in a row's cell still asks with the conflict bar.
Dragging a pane (a docked pane's title or a floating pane) over another
pane docked at a side edge offers two dock zones: the outer third docks
it directly outside that pane, the inner third directly inside it. The
middle third is no target. The window-edge strip docks a pane outermost
on that edge. The new PaneRequest::Before(pane, before) asks the app to
move the pane to directly before another in its open list, which sets
its position on the edge; the drop preview is laid out from that order,
so it matches where the pane lands. With one slot per edge, a closable
pane dropped on an edge takes the slot.
DockContent::group_extra_tabs_width and group_extra_tabs draw host tabs
right after a group's panel tabs, before the drag bar and the header.
They fit with the panel tabs as one more tab that never overflows: both
shrink widest first to min_tab_width, and in a narrower row the panel
tabs overflow while the extra tabs keep that width.
* 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
* craft-menu: shrink-to-fit bar, bar runs Quit and Minimize, mnemonic before an ellipsis documented; craft-keymap: parse the minus sign
* craft-keymap: test the arrow glyphs as keys
* craft-menu: mac::install_with and MacOptions::window_list, for apps that list their documents themselves
* craft-menu: a negative fit limit draws no bar; Window list docs name the Window menu
A native floating window is an egui pass of its own, and can draw several
panel bodies. A Composer drawn there records its descriptor, and the dock
area publishes it once, after the window's last body, so a body drawn after
the editor's cannot clear it and end the composition. DockContent::window_drawn
runs at the same point for apps that publish their own descriptor.
* 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
JeremyandClaude Opus 5.5
Dylan M. Taylor
aiongg
aiongg
enriquemelzer-bitandenriquemelzer-bit
skylar taylor-barrick