On Linux the save dialog is the XDG desktop portal's, shown through
rfd. rfd sends no `current_filter` and reads only the file name from
the portal's answer, and the GTK file chooser keeps the typed name
when another file type is picked. With "PDF-compatible .ai" picked,
`poster` typed for a new document was saved as a native
`poster.vectorcraft`, and so was the suggested
`Untitled-1.vectorcraft` left as it was.
When a save offers two or more file types (Save As, Save a Copy, Save
as Template and the first Save of a new document), the app now calls
the portal's SaveFile itself over D-Bus. The dialog starts on the
suggested file's type, and its answer names the type picked. A name
typed without an extension, or the suggested name left as it was,
gets that type's extension. A name typed with another save format's
extension, other than the suggested file's (for Save as Template, a
template format's), is saved in that format, and any other extension
gets the picked type's added. The dialog keeps the window as its
parent on X11 and Wayland, and rfd shows the dialog when the portal
can't. The same code runs on the BSDs; Windows, macOS and the web
build keep their dialogs.
Docs: docs/target-app-parity.md.
The Color Picker gets an eyedropper button beside the New and Original
chips, and `ui.sampleScreenColor {stroke?, picker?}` shows the system's
color sampler. The command answers at once. When the person clicks a
color anywhere on the screen, the color becomes the fill or the stroke
through paint.setFill / paint.setStroke as one undo step, or with
`picker` it becomes the open Color Picker's color, which previews on the
selection as any pick does. Escape cancels the sampler. The sampled sRGB
color goes through Cms::srgb_to_rgb, so in a Display P3 working space a
color inside sRGB shows as it did on the screen. `ui.inspect` reports
`screenSampler` while the sampler is open.
- macOS uses NSColorSampler (apps/vectorcraft/src/mac_screen_color.rs).
- The web app uses the browser's EyeDropper API where the browser has
one.
- Without a sampler (Windows, Linux, other browsers) the button is gray
and the command returns an error. Keyboard Shortcuts lists the
command, so it can be given a key.
Docs: docs/control-protocol.md, docs/target-app-parity.md.
Fix#1726 with idle, absolute line and reply-write deadlines and connection-slot guards. Add real-loopback regressions and document reconnect behavior.
Validated with cargo xtask ci: all seven gates passed; 6156 tests passed, zero failed, seven existing ignored.
On a hybrid laptop whose Wayland compositor runs on the discrete GPU
(Hyprland with AQ_DRM_DEVICES naming the NVIDIA card first), the built-in
panel still hangs off the integrated GPU, so the display rule put it first,
and the window stayed empty: the compositor took the frames and showed
nothing, with no error, so neither the restart on a failed adapter (#502)
nor the first-frame watch (#964) noticed.
Which GPU drives a display stands in for which GPU the compositor draws
with. Under Wayland the compositor says so itself: the main_device of its
linux-dmabuf feedback (version 4), the device it imports client buffers on,
which Mesa's Vulkan device-select layer reads for the same purpose.
compositor_gpu.rs asks for it on a short-lived connection, maps the dev_t
to PCI ids through /sys/dev/char, and under Automatic adapter_order ranks
that adapter ahead of the display GPUs. No answer (X11, an older compositor,
a GPU no adapter matches) leaves the existing rules in charge; a user's own
choice, WGPU_ADAPTER_NAME and the restart skip list still come first.
wayland-client and wayland-protocols are already in the tree through winit;
they become direct Linux-only dependencies.
The crash: rfd's blocking dialog ran -[NSSavePanel runModal] inside
winit's event handler; when a resize of the panel ends, AppKit runs the
closures winit queued meanwhile, and winit's re-entrancy panic fires
inside an Objective-C block, where it can't unwind, so the app aborts.
As PhotoCraft (#673) and PdfCraft (#145) ship it:
- macOS: picks::ask shows an rfd::AsyncFileDialog as a sheet on the
window (beginSheetModalForWindow returns at once); a waiter thread
sends the paths and wakes the window. A pick asked outside an entry is
refused and logged instead of running a modal. Linux keeps its thread
(#592) and now also wakes the window; Windows is unchanged.
- Nine paths that asked outside an entry now run as entries: Load
Profile, Swatches and Graphic Styles Other Library, the shortcut
editor's Import and Export, and the presets dialogs' Export.
- While a dialog is open: the macOS menu bar is inert except Hide, Hide
Others and Minimize; Quit, Close, Close All and the close button are
refused; Finder/Dock opens and the IME discard wait; another dialog
is refused with a status message. The answer re-activates the
document that asked (by uid) and Save Changes finds its document by
uid; a frame guard clears a stale picks entry after a recovered panic.
- ui.inspect reports fileDialog.
Squashed onto current main by the maintainer (with main's automation
sandbox wrappers and font-name menus kept).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AppKit places close, minimize and zoom in a standard title bar, shorter
than the 44-point app bar they sit over, so they rode high on it. They
are now moved to the middle of the bar, inset from its left as far as
from its top, with the title bar container made as tall as the bar so
they stay clickable. AppKit lays the title bar out again on resize and
when leaving full screen, so the placement runs every frame and sets a
frame only when it is out of place. The app bar keeps the room the
buttons take, measured, instead of a fixed 78 points.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a desktop with a Ryzen integrated GPU without a monitor and an NVIDIA
card driving both monitors, Automatic (power saving on Windows) picked
the integrated GPU; Windows presented every frame across adapters and
the integrated GPU's driver reset, losing the graphics device or taking
every monitor down for minutes (same bug as pdfcraft#378).
Automatic now asks the system which GPU drives which display (Windows:
EnumDisplayDevices through winsafe; Linux: /sys/class/drm) and ranks the
GPU driving a display, and among those the primary display's, ahead of
the power preference. Where the system can't say, or no adapter's PCI
ids match (OpenGL, Metal), the order is the power preference's as
before, so nothing gets worse. Power Saving and High Performance chosen
by the user, and WGPU_POWER_PREF, keep ordering by kind alone.
The log now lists the display GPUs, which adapters drive a display, and
the adapter drawn on with the reason, the first question in every
black-window report. Tests cover the device-id parser, the rankings
(desktop with all monitors on the discrete GPU, hybrid laptop, a monitor
on each GPU, no match), the sysfs reader and a live EnumDisplayDevices
call.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ZwZjADUZP4VzvrFGpiZch
The font scan read only the macOS font folders and the Additional
Fonts Folder, so fonts that apps and font managers register with
CoreText from their own folders were missing from the font menus, and
exports set such type in the fallback font. CoreText's font manager
lists them with the installed fonts.
- `mac_fonts.rs` lists the files of the fonts the font manager has
available (`CTFontManagerCopyAvailableFontURLs`, through
objc2-core-text), keeping only file URLs as `open_documents.rs` does
(#433). The desktop app and `vectorcraft-cli` install it as they
install the DirectWrite lister on Windows, and the scan reads the
files outside the font folders in place.
- The scan leaves out faces with no outlines the font engine draws (no
glyf, CFF, CFF2 or VARC table), on every platform. CoreText lists
Apple's PingFang UI interface font (macOS 27), whose outlines are in
an hvgl table; if the scan cataloged it, PingFang SC would count as
installed, and Chinese characters in fallback text, Japanese kanji
included, would draw blank.
- Tests: the list holds the installed fonts by full path, a font
registered from another folder is listed while it is registered, and
a face without outlines the engine draws isn't cataloged.
Font services load their fonts with GDI at run time, from files in their
own folders, without installing them: neither the font folders nor the
registry list them, so the font scan never saw them. DirectWrite's system
font collection holds them since Windows 10 1607.
- vectorcraft-text: `set_platform_font_files` lets the app name font files
the platform knows; each scan and each check for installed fonts asks
again and reads those outside the font folders. A file named by itself
is read whatever its extension (font services keep fonts in files
without one).
- The desktop app lists the local files of DirectWrite's system font
collection on Windows (`system_fonts.rs`, through the windows crate
already in the build), read in place.
- The check for fonts installed while the app was in the background runs
on a thread: DirectWrite's check for updates takes about 50 ms.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On macOS the menus are in the system menu bar, laid out as a Mac app's (Illustrator on the Mac as
the reference), and the app settings sit in the VectorCraft menu: About, Settings ▸ (one item per
Preferences page, General… ⌘K), Language ▸, Appearance ▸ (UI brightness), Services, Hide
VectorCraft ⌃⌘H (⌘H stays View › Hide Edges), Hide Others ⌥⌘H, Show All and Quit ⌘Q (the app's own
quit, so unsaved documents are asked about); they leave Edit and Help. Window gets Minimize ⌃⌘M,
Zoom and Bring All to Front; Help is the system's Help menu. Windows, Linux and the web keep the
in-window menu bar unchanged; --in-window-menus or VECTORCRAFT_IN_WINDOW_MENUS keeps it on macOS
too, and so does a menu bar AppKit refuses to build.
One menu model: the in-window menus and the native bar draw the same rows (menus::entry), and the
platform-free native_menu module lays them out, decides when to update (a cheap state hash; labels,
enabled and checked in place, a rebuild only when the structure changes) and hands key equivalents
back to egui as the key presses they were, so shortcuts, user overrides and focused text fields
behave as in the window and nothing fires twice. The muda backend (pinned =0.21.1, macOS only, no
unsafe) is apps/vectorcraft/src/mac_menu.rs, mirroring PhotoCraft's. ui.inspect reports
nativeMenuBar. Translations for the new labels in ja, es, zh-hans, zh-hant, cs and pt-br.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A screenshot on the clipboard didn't paste everywhere:
- macOS: the Paste menu item (which takes Cmd+V there) was enabled for text
only, so with nothing copied in the app Cmd+V did nothing; and arboard
reads the pasteboard's TIFF only. The pasteboard's types now enable Paste,
and its PNG, else TIFF, pastes as it is.
- Windows: bitmaps came through CF_BITMAP and GetDIBits, which drops alpha.
Paste now reads PNG, else CF_DIBV5, else CF_DIB, decoded with their colour
masks and tables (a BMP file header in front, which image's headerless
decoder gets wrong for masks after a BITMAPINFOHEADER), opaque when the
alpha is zero throughout as screenshots leave it, capped at 32768 px a side.
- Web: only SVG text pasted. The page's paste event now hands the first
picture or file that is art to the app (VectorcraftApp::paste_from_host),
pasted with the chord held, like the desktop's paste keys.
- Linux reads image/png already; its Paste menu item still waits for text
(no cheap way to ask arboard for a bitmap), the paste keys take one.
Bitmaps paste as embedded images at the view centre, as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Under Wayland the window is native but arboard was built without its
data-control backend, so it read the X11 clipboard through XWayland,
which only holds what X11 apps copied: Paste found nothing and reported
an empty clipboard (egui's text paste into fields uses smithay-clipboard,
which is why that worked). arboard now has `wayland-data-control`, the
same as PhotoCraft; it falls back to X11 where the compositor lacks the
protocol (GNOME's Mutter).
The reporter's clipboard also held text/uri-list: with a file copied in a
file manager, Paste would have taken the path as text before the bitmap.
Copied files now paste first, as the first one that is art (SVG, PDF,
EMF/WMF or a bitmap), told from its first 4 KiB by the engine's format
detection (`clipboard::file_flavour`): text/uri-list through arboard on
Linux and macOS (a trailing CR from CRLF lists trimmed), CF_HDROP on
Windows, read with the clipboard closed again.
Dropping files on the window can't work under Wayland yet: winit 0.30,
which eframe 0.36 runs on, has no Wayland drag and drop (winit#1881,
added in 0.31), so no dropped_files arrive. docs/development.md documents
it and the workarounds (copy and paste the files, File > Place, or run
under XWayland with `WAYLAND_DISPLAY=`).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Finder, Open With, a drop on the Dock icon and `open -a` failed with "VectorCraft cannot open
files in the PDF document format":
- The release Info.plist declared no document types, so Launch Services refused the files before
the app saw them. Info.plist.in now declares every format File › Open reads (the engine's
OPEN_EXTS; a test keeps them in step): VectorCraft owns its own documents and templates and is an
alternate for the others, so it takes over no other app's files. `cargo xtask bundle` now fills
in the same template instead of its own, shorter plist.
- macOS delivers such files as open-document events, not arguments. winit 0.30's application
delegate has no `application:openURLs:`, so AppKit fell back to NSDocumentController, which
refuses every file of a non-NSDocument app (the error in both issues). The new
`open_documents` module adds that method to the delegate's class when the app is about to finish
launching (before AppKit delivers launch files), queues the paths and wakes the UI, which opens
them with `io::open_path` like command-line files; errors go to the status bar too.
New direct macOS dependencies `objc2-foundation` 0.3 and `block2` 0.6 were already in Cargo.lock
(through winit, muda and rfd). The module allows `unsafe_code` for the Objective-C runtime call.
Fixes#354
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Typing with an input method (the macOS Japanese IME and the like) used to
insert the raw keys (romaji came in as ASCII): egui's Ime events weren't
handled.
- Tools gain `ime_preedit` / `composing` / `ime_caret`; the Type tool lays
the marked text out in place inside its typing session, underlined (the
clause being converted thicker), and commits it through `text_input`.
Character ranges from the IME convert to byte ranges in one place. A
cancelled composition leaves no empty undo step; an empty clear with
nothing marked never deletes the selection.
- The UI sends Text and Ime events to the tool in order, sends IMEOutput
every frame while text is edited (what lets egui-winit enable the IME
and place its candidate window at the caret, or the converting clause),
and holds back keys, Enter/Escape, clipboard, single-key shortcuts and
menu commands (Undo, Cut, Select All… also from the native menu) while
composing. A click, a tool switch or a style change ends the
composition with the marked text kept as typed; on macOS the IME is
told to discard it (NSTextInputContext.discardMarkedText) so it doesn't
come back in the next input.
- Undo during a typing session also ends the Type tool's session, so its
caret and marked text follow the document.
- Tests: tools (char → byte ranges, underlines and candidate position),
engine (compose → commit is one step, cancel leaves no step, a click
commits, Undo mid-composition is safe), ui-egui (synthetic Ime events:
compose, commit, ⌘Z held back, IME output, click and app switch).
Checked by hand on macOS 27 with the Japanese IME (romaji input, convert,
commit, cancel, Undo/Redo after commit, click away, Latin mode, app
switch). Not checked: Windows and Linux IMEs, the web build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The first window opens at 1440 x 900 when the screen has room for it around a
taskbar or Dock, and maximized (with a size that fits once un-maximized)
when it doesn't, as on 1600 x 900, 1366 x 768 or 150% scaled 1080p screens.
The window's size, position and maximized state are saved with the UI
preferences (UiState::window) and restored at the next launch, moved fully
onto a monitor that is still connected and maximized if it no longer fits.
Root cause: main.rs created the window at a fixed 1440 x 900 at the system's
default position, never checked it against the monitor and never remembered
it. The new apps/vectorcraft/src/window.rs places the still-hidden window
from the monitors winit reports (CreationContext::winit_window) and tracks
its geometry every frame.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copy and Cut also offer other apps a PNG of the copied objects, a PDF
with On Copy: PDF, and plain text when every copied object is type
(clipboard.flavours; clipboard.exportPng {scale?}, exportPdf,
exportText). Paste outside text editing takes what another app copied:
SVG, then PDF (clipboard.importPdf), then plain text as point text
(clipboard.importText), then a bitmap embedded at the view centre
(clipboard.importImage {dataBase64, mime?, center?}); pasting our own
copy keeps the lossless internal clipboard, and Cmd+V pastes a bitmap
that comes with no text. Services gains system_clipboard
(SystemClipboard: write, holds_ours, read, has): on Windows every
format at once, on macOS and Linux one (the text, else the PNG); the
web keeps SVG text only. With When pasting text: Keep Plain Text, text
the Type tool copied pastes without its formatting.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Daniel