* packaging: Flatpak finds and prints to CUPS printers
The Print dialog listed no printers in the Flatpak: the runtime has libcups but not
lpstat/lp, the sandbox couldn't reach the CUPS socket, and driverless network printers
(lpstat -e) need Avahi. Bundle lpstat/lp/lpoptions from CUPS 2.4.20 (Apache-2.0,
statically linked, licence installed) and grant --socket=cups and
--system-talk-name=org.freedesktop.Avahi in both manifests.
* packaging: Flatpak reads the user's CUPS settings (~/.cups, read-only)
Review (CodeRabbit): without it the sandbox's lp/lpstat ignore the user's default
printer and saved options (lpoptions) and a print server named in their client.conf.
* packaging: Flatpak CUPS tools reach the host socket when client.conf names a custom path
Review: Flatpak mounts the host's CUPS socket at /var/run/cups/cups.sock whatever
path ~/.cups/client.conf or CUPS_SERVER names, so lp/lpstat/lpoptions now run through
a wrapper that points a socket path missing in the sandbox there. Server names
(remote servers) and sockets that exist are left alone. Tested in the sandbox:
CUPS_SERVER=/run/custom/cups.sock lists the host's printers through the wrapper and
none without it; a host name is passed through unchanged.
* packaging: redirect a custom CUPS socket only when it is the one Flatpak mounted
Review (CodeRabbit): Flatpak picks the socket it mounts at /var/run/cups/cups.sock
with stricter rules than CUPS (flatpak-run-cups.c: a socket CUPS_SERVER, else the
first line spelled exactly "ServerName /path" in ~/.cups/client.conf, else the
default), while CUPS reads the keyword in any case and takes the last ServerName. The
wrapper now redirects only when CUPS' socket is the one Flatpak chose, so a job can't
reach a different server; otherwise CUPS fails on the missing path.
* packaging: never redirect a CUPS_SERVER the sandbox was given
Review (CodeRabbit): Flatpak picks the socket it mounts from the host's CUPS_SERVER,
so one set by flatpak run --env or an override may not be what it mounted. The
wrapper now leaves any CUPS_SERVER alone and redirects only a client.conf socket that
matches Flatpak's choice; otherwise CUPS fails on the missing path instead of
reaching a different server.
* packaging: point CUPS at the mounted socket only when it is the one Flatpak chose, else fail
Review (CodeRabbit): with a custom socket listed first and the default last in
~/.cups/client.conf, Flatpak mounts the custom one at /var/run/cups/cups.sock while
CUPS picks the last line, finds that path, and talks to the custom server. The
wrapper now compares CUPS' socket with Flatpak's choice even when the path exists:
equal, CUPS is pointed at the mount; different, the tool fails with an error instead
of reaching another server.
Every Preferences dialog option is read by shipped code, by its field or
its key, except five, each waiting on a subsystem of its own: Open
Documents As Tabs (documents in floating windows, G7), Units > East Asian
Type, Hyphenation > Default Language, Scratch Disks, and the legacy vector
clipboard. Highlight Alternate Glyphs, Real-time Drawing and the Devices
options, still listed as stored-only, act. Docs only.
A layered .ai or Illustrator EPS whose editing data (embedded rasters,
mostly) unpacks past 512 MiB opened as its PDF part or printed page, in
one layer, with "it decompresses to more than 512 MB" (#4628 on 0.17.0
hit the older 256 MiB limit the same way).
The limit is now an eighth of installed memory, from 512 MiB (what every
64-bit build read before) to 2 GiB: 1 GiB on an 8 GiB machine, 2 GiB on
16 GiB or more. Reading takes about as much memory again as the data
(1.1 GB of data with 24 embedded 4096 x 4096 images peaked 1.1 GB above
the start), so the ceiling keeps a small file that unpacks without end
from taking a large machine's memory. 32-bit and web builds keep 256 MiB.
vectorcraft_render::installed_memory exposes the reading the image cache
already sizes itself from.
Two ways the next launch came back with settings from before:
- The workspace, panels, toolbars and other settings kept only in the UI
state were written only on quitting (Preferences OK already saved at
once, #1747). A session ended any other way lost them. The app now
saves within 2 seconds of a change, and only when something changed.
- Each launch is its own process, so two windows are common (opening a
second file from the file manager). A window wrote back the whole
state it started from when it quit, so the one quitting last put back
the settings it read at its start, even with nothing changed in it.
A window now saves only what it changed since it last read or saved,
merged into the file as it is: each UI field, and each engine
preference on its own. A setting both windows changed takes the last
save.
The status line, open dialog and other fields a start resets neither
trigger a save nor replace another window's.
With the Direct Selection tool active (after the bar's Edit Path, or
switching to it) and a path selected whole, the Contextual Task Bar kept
the Selection tool's Edit Path, Offset Path and Simplify: its anchor
actions showed only for anchors picked out one by one.
The public overview lists, for a path the Direct Selection tool selects,
Simplify and the anchor actions. A path selected whole now offers Corner
and Smooth (path.convertAnchors converts every anchor of a fully
selected path), Connect for an open path, and Simplify. Remove Anchor
Points and Cut Path need anchors picked out and still wait for them.
Edit Path, which only switches to the tool already in use, is left out,
for compound paths too.
Art dragged off the canvas reached the panels (Asset Export, Graphic
Styles, Swatches, Symbols) only from the Selection tool: drag_art_out
checked for that tool by id. With the Direct Selection or Group
Selection tool the move stayed on the canvas, so nothing dropped.
Those tools now hand over a move too when every selected object is
selected whole (a press on its fill). A drag of anchor points or
segments, which they also call Move, stays a reshape and isn't handed
to the panels.
The Flatpak on GNOME has no X11 (fallback-x11 on a Wayland session) and GNOME offers
no data-control protocol, so arboard::Clipboard::new() failed every time. The handle
was kept only on success, so the background Paste check reconnected to the compositor
and logged a warning every 250 ms: 267k warnings in 18 h, the 16 MB log full in 3 h.
- A clipboard that can't be opened is tried again after 1 s, doubling to a minute.
A Copy or Paste of the user's retries at most once a second.
- The outage is logged once (WARN) and its end once (INFO), across the UI's and the
background check's handles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merges kept prepending each side's whole summary as "previously: …", so
target-app-parity.md's status line had grown to 66 MB (839 copies of its
Target clause), gaps.md's and ui-parity.md's to over 1 MB. Each status
line now names its latest change only, as the progress-docs standard has
it; the revision histories keep the earlier ones.
Eraser Tool Options' Size takes Fixed or Pressure and a Variation as the
Blob Brush's does: the tool records the pen, and path.eraseRegion outlines
the squashed drag at the pen's widths, stretched back to the tip's angle
and roundness. The pressure parsing and outline move to draw2's common
helpers, shared by both commands.
Blob Brush Tool Options' Size takes Fixed or Pressure and a Variation, as
the brush options' Size does: with Pressure the brush is Size − Variation
wide where the pen presses lightest and Size + Variation where it presses
hardest. The tool records the pen pressure of each point and shows each
step of the drag as wide as the pen pressed there; path.blob takes
[x, y, pressure] points with sizeMode and sizeVariation and outlines the
stroke with that width profile. A stroke without pressure keeps the Size,
and Fixed with no variation stays the default.
https://helpx.adobe.com/illustrator/desktop/paint-and-fill/learn-painting-basics/blob-brush-options-and-best-practices.html
The frame a trace starts in may already have asked for its next one before the trace started, so with no input the finished trace could wait. From the review of #4617.
From the review of #4605. TraceParams::swatches isn't in the settings' JSON (serde skip), so a Document Library trace whose swatches were edited while it ran still applied, with the old colours; the trace's inputs now hold them. The 100 ms repaint that keeps background work moving left traces out, so without input a finished trace could wait for the next event.
Dylan M. Taylor