Commit Graph
404 Commits
Author SHA1 Message Date
BFlat 234d8bce3d Merge pull request #7209 from dotCooCoo/fix/portal-save-portal-exit
Save As: on Linux a portal that exits during the save dialog no longer leaves the save waiting
2026-11-14 01:54:21 +07:00
dotCooCoo 4dad65667f Save As: on Linux a portal that exits during the save dialog no longer leaves the save waiting
When the desktop portal's process exited while its save dialog was
open, no Response came. The stream that save_file read does not end
while the session bus stays up, so the save waited forever on the
calling thread and rfd's dialog never showed.

save_file now waits with the screen color sampler's Responses, which
moves from linux_screen_color/request.rs to portal_request.rs and is
built on Linux and the BSDs. Before the call it listens for the
Response and for the bus's NameOwnerChanged for the portal's name, so
the wait ends with an error when the connection that replied leaves
the bus, and the caller shows rfd's dialog, as for other portal errors.

When the bus reports the portal gone, the wait first reads the
Responses already queued, so an answer the portal sent before it left
is still the answer. Before, the sampler's wait could take the bus's
report while that answer was queued and end with an error.

The mock portal gains three modes that close its connection after the
reply: 300 ms later without a Response, at once without a Response,
and at once after the Response. The private bus helper of the
sampler's tests moves to portal_request.rs, and the save dialog's
tests use it, so a failing test also stops its bus.
2026-11-13 09:41:13 -08:00
dotCooCoo 0fd757c6b8 Clipboard: the window closes at once and quitting waits up to 27 s for the Paste check
On Linux the Paste menu's background check holds its own clipboard
handle. When the app quit while that check's X11 text read was still
unanswered, quitting stopped waiting for the check's thread after 5 s,
but the handle's read worker holds arboard's handle until 25 s after the
read was sent. The app's own handle was then dropped first, so it was
not the last one alive to hand what was copied to a clipboard manager.

- CLIPBOARD_PROBE_STOP_WAIT (27 s, exported from vectorcraft-ui-egui)
  replaces the 5 s bound: the 25 s X11 read limit plus LOAD_WAIT, the
  2 s limit on waiting for a reader to stop. Quitting still ends after
  it when a host's handle never lets go.
- On Linux and the BSDs, on_exit hides the main window before eframe
  drops the app, so the window closes at once while the process waits
  for the clipboard handles. The window is hidden, not closed, and the
  connection the clipboards use stays open. winit hides X11 windows,
  XWayland ones included; it cannot hide a native Wayland window, which
  stays on screen until the wait ends. macOS and Windows are unchanged.
- Probe's Drop waits through an injectable function, so a test drives
  the wait with a controllable clock while the probe's handle is still
  being dropped and checks that it is dropped before the app's.
- A Linux test in the app checks the bound against X11_READ_LIMIT and
  LOAD_WAIT, so raising either fails it.
- Comments and docs/development.md describe the wait.
2026-11-13 04:33:41 -08:00
dotCooCoo 7907bae6c3 Merge main into feat/new-document-profiles 2026-11-12 13:42:10 -08:00
dotCooCoo 22a19db2cd Merge main into feat/new-document-profiles 2026-11-12 09:29:46 -08:00
dotCooCoo fe34c2b818 Merge main into feat/custom-arrowheads 2026-11-12 09:23:20 -08:00
BFlat 1c50241ddd Merge pull request #6702 from danngreen/fix/mac-cursor-after-move
macOS: the canvas cursor stays after the pointer moves (#6362)
2026-11-12 23:53:03 +07:00
BFlat 0cb73d0d66 Merge pull request #6845 from dotCooCoo/feat/linux-screen-color-portal
Color: Sample Color from Screen works on Linux through the desktop portal
2026-11-12 23:10:13 +07:00
BFlat 6bd9b9e50d Merge pull request #6870 from dotCooCoo/fix/portal-save-filter-shape
Save As: a save goes ahead when the portal answers with a file type of another shape
2026-11-12 22:02:14 +07:00
Dan Green cea0eb8358 macOS: the canvas cursor stays after the pointer moves
The AppKit cursor adapter set its cursor again only when
NSCursor.currentCursor differed from it. But that is the app's last set
cursor, not the one on screen: when the pointer moves, AppKit can put
the system arrow back while currentCursor still reads as ours, so the
adapter kept the arrow. Pressing V over the canvas showed the Selection
tool's arrow, and the first move replaced it with the system pointer.

While it owns the cursor, the adapter now sets it on every pass. That
costs nothing when it is already showing.
2026-11-12 06:59:40 -08:00
dotCooCoo e29f5e51a0 New Document: each preset category starts documents from its own profile
Each built-in category (Mobile, Web, Print, Film & Video, Art &
Illustration, Branding, Social) has a New Document profile, a native
document in the New Document Profiles folder next to the preferences.
file.new copies the profile's swatches, graphic styles, brushes, symbols,
patterns, character and paragraph styles, rulers, Document Setup options,
assigned color profiles and print settings into the new document. The
preset's size, units, artboards, bleed, background, color mode and
resolution still apply, and the profile's art and layers are not copied.

- file.newProfiles lists the profiles, file.newProfiles.edit opens one
  as a document (writing the shipped profile first), and
  file.newProfiles.reset deletes its file. file.new takes `profile`.
- Saved and Recent presets keep the profile of the preset they came from.
- A profile that cannot be read, is larger than 64 MiB or is not a native
  document leaves the defaults, and file.new reports it in profileError.
- New Document has a Manage Profiles pop-up with Edit and Reset.

Docs: docs/mcp.md, docs/target-app-parity.md.
2026-11-12 06:00:40 -08:00
dotCooCoo 8db00cbbe2 Merge main into feat/linux-screen-color-portal 2026-11-12 05:54:25 -08:00
dotCooCoo 43b6a793b4 Color: the screen color sampler's bus tests wait for the answer without a time limit
The tests call the sampler's pick directly instead of giving it 30 seconds on another thread.
2026-11-12 05:54:24 -08:00
Ahmed Gomaa 421fead32b Merge upstream main into file/save-read-only-offers-save-as 2026-11-12 15:24:23 +02:00
dotCooCoo 366d09d285 Save As: a save goes ahead when the portal answers with a file type of another shape
The save dialog read the portal's current_filter with zvariant's tuple
conversion, which panics on a structure with fewer fields than the
tuple. On Linux and the BSDs the dialog's thread then ended after the
user picked a file, and nothing was saved. The label is now read only
from a (sa(us)) structure, the shape the FileChooser portal defines.
An answer of another shape keeps the path and names no file type, as
an answer without current_filter does. A structure with more fields
than (sa(us)) also no longer names a file type.
2026-11-12 05:09:40 -08:00
BFlat 89fba4ebfd Merge pull request #5446 from Taha-Mahmoodi/fix/import-document-title
Fix #3626: an imported document takes the title the file carries
2026-11-12 20:09:15 +07:00
dotCooCoo 5e80810605 Merge main into feat/custom-arrowheads 2026-11-12 05:00:21 -08:00
Taha-Mahmoodi 3628ad98e9 Merge commit '5a9c297608fc5456bb682c71cbd441339d4504e7' into fix/import-document-title 2026-11-12 16:19:03 +04:30
Ahmed Gomaa c66335eaa7 Merge upstream main into file/save-read-only-offers-save-as 2026-11-12 13:40:13 +02:00
dotCooCoo 6a6a1baa28 Color: the screen color sampler names its Wayland parent on its own thread
Exporting the window for the portal waits for the compositor to answer. The
sampler now does it on its worker thread, as the portal's save dialog does,
so a slow compositor does not hold up the UI.
2026-11-12 02:21:22 -08:00
dotCooCoo e6d5c8846e Color: Sample Color from Screen works on Linux through the desktop portal
On Linux, ui.sampleScreenColor and the Color Picker's eyedropper button
now show the XDG desktop portal's color sampler (Screenshot.PickColor,
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Screenshot.html).
A thread of its own makes the call and waits for the person, and the
picked sRGB color goes through the same conversion into the working RGB
space as on macOS and the web. A cancel leaves the colors as they were.

A session without a portal that has PickColor, a portal that does not
return from the call within 25 seconds (VectorCraft's own limit) or
leaves the bus before it answers, and a portal that ends the request in
another way each show a status message and end the wait. The two new
messages are translated in every catalog that has the sampler's other
messages. The request token is random, as the Request documentation
asks (https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Request.html).

The window is named for the portal on the UI thread, as for the save
dialog, and the sampler's thread keeps the window and its export until
the portal answers.
2026-11-12 01:12:13 -08:00
dotCooCoo 7da7c2c456 Merge main into fix/artboard-files-ask-before-replacing 2026-11-11 23:51:03 -08:00
dotCooCoo b262d10e89 Save and Export: files written beside the picked one ask before replacing a file there
A save or export that writes a file per artboard, linked images or image
maps names them after the file picked in the save panel, which asked only
about that name. A file already there under one of the other names was
replaced without a question.

Save As, Save a Copy, Save as Template, Save and Export now check those
files before writing anything. When any is there, nothing is written and
a replaceFiles question names it (and lists all of them when there are
several). OK runs the save or export again on the document that asked and
replaces the named files; a file it would now write that the question did
not name is asked about again. Cancel writes nothing. A background save
or export checks from its worker and asks once it ends, after a dialog
open then. Files the document's last Save or Save As wrote are replaced
without asking.

Services::exists is now an Arc<dyn Fn(&str) -> bool + Send + Sync>.
2026-11-11 23:39:32 -08:00
BFlat 5e63104d88 Merge pull request #6800 from dotCooCoo/fix/plugin-automation-install-approval
Plug-ins: an install that automation asked for is not approved in its dialog
2026-11-12 14:16:59 +07:00
Taha-Mahmoodi 5a9c297608 Compile clipboard failure helper only for its callers 2026-11-12 11:36:34 +04:30
dotCooCoo 264eeec475 Merge main into feat/custom-arrowheads 2026-11-11 22:30:03 -08:00
dotCooCoo ad05c3b99d Plug-ins: an install that automation asked for is not approved in its dialog
An approval question that a control request, MCP, injected input, or a
file dialog one of them opened leads to now keeps OK disabled and
refuses every confirm, a person's click included. The dialog says to
choose Object › Plug-ins › Install Plug-in…, and ui.installPlugin answers
approval: "personMustStartInstall". The person's own Install Plug-in…,
File › Open or drop inspects the module again and asks a new question
with its half-second delay.

The origin is fixed when the request is made and goes with a native
file dialog's deferred answer and the web picker's answers, which now
arrive apart from drops and from window.vectorcraft.openFile (always
automation). A question about taking another module's place now opens
in the approval dialog, and automation's replace: true no longer skips
it. A module that needs no approval still installs at once.
2026-11-11 21:56:58 -08:00
dotCooCoo c1f7e2eeaf Stroke: custom arrowheads from an arrowheads file join the arrowhead menus
The Stroke panel menu's Edit Arrowheads… (stroke.arrowheads.edit) opens
Arrowheads.vectorcraft next to the preferences, creating it with one
example head when it is missing. Each symbol in the file is one head,
listed by name after the built-in heads in both arrowhead menus: it
points right, its registration point is the tip, and its height is drawn
as wide as the built-in heads. The file is read at startup and again
each time VectorCraft saves it; stroke.arrowheads.reload and
stroke.arrowheads.list read and list it.

Arrowhead gets a Custom variant, appended after the built-in names, that
carries the head's name and outline, so a document that uses one draws,
saves, reopens and exports it without the arrowheads file. stroke.set
takes {"custom": name} or the {"Custom": {name, path}} form that
document.inspect reports.

Part of #5421.
2026-11-11 21:52:46 -08:00
dotCooCoo 832fad16e0 Merge main into feat/hang-report 2026-11-11 21:17:30 -08:00
Dylan M. Taylor a971a14898 Fix Flatpak updates and bump to 0.24.1 (#6649)
* fix(flatpak): allow release checks and self-update helpers

* test: keep Flatpak permission parsing within strict Clippy rules

* chore: bump version to 0.24.1 for the Flatpak update fix

* test: locate CLI binaries after Nextest archive relocation

* docs: explain the Flatpak update permission bootstrap
2026-11-11 21:30:40 -05:00
dotCooCoo d7a32d09ec Merge main into feat/hang-report 2026-11-11 18:28:39 -08:00
BFlat ed412fb73b Merge pull request #6661 from dotCooCoo/fix/clipboard-read-time-limit
Clipboard: Linux and BSD reads wait 2 s at most for the app that copied
2026-11-12 09:22:11 +07:00
dotCooCoo e9942b69d2 Help: a frame run while a file dialog waits is timed for the hang report
The input hook, the logic and the interface of a frame now mark their
time as timed whatever the activity around them, so a frame the system
runs while an in-line file dialog waits for the user is timed too, and
the dialog's wait is not timed again once the frame ends.
2026-11-11 17:36:11 -08:00
dotCooCoo 7f5e4519a5 Help: input in a focused floating window is timed for the hang report
The end of a frame counted the renderer as busy only when the main
window had the focus, so a stall drawing input in a focused floating
panel or document window wrote no hang report. A floating window that
has the focus and is not minimized now counts too. A frame that sends
that window commands to minimize or hide it, or to move or resize it,
ends idle, including commands its own pass sent, which are noted
before egui passes them on.
2026-11-11 17:26:09 -08:00
dotCooCoo ab91a4a705 Clipboard: a paste after a late answer reads the clipboard again
The app that answers a late read may have lost the clipboard while the
paste waited. Once the answer comes, the paste makes the same read again
and uses the new answer, for arboard's reads and the core protocol's
text read alike.
2026-11-11 17:23:43 -08:00
dotCooCoo 892d87ce55 Clipboard: a paste's reads after a late answer wait as long as the paste
The text and file-list reads that follow a late answer now wait until
10 s after the unanswered read was sent, not 2 s from when they start,
so a slow text answer is still pasted. Text that is blank or names a
picture is replaced by the bitmap only when the paste asks for one.
2026-11-11 17:16:05 -08:00
dotCooCoo d8be61ddb1 Help: making a save dialog's folder is timed for the hang report
An in-line save dialog that first makes its folder marked the folder
work as the dialog too, so a stall in making the folder wrote no hang
report. The folder is now made before the dialog is marked, on the
background dialog thread as well, and a test checks the order.
2026-11-11 16:27:24 -08:00
dotCooCoo 2ce702eda0 Clipboard: a paste after an unanswered Wayland text read waits for its answer
The core-protocol text clipboard (used where the compositor has no
data-control protocol and there is no X11) failed a paste at once after
its 2 s read timeout, so the paste took the internal clipboard even when
the other app's text came within the paste's 10 s limit. It now keeps a
text read that got no answer in its wait, as the arboard path does, and
the paste waits for that answer on its background thread until 10 s
after the read was sent. The answer is pasted unless it is empty or the
text copied here.
2026-11-11 16:20:52 -08:00
dotCooCoo 14c8385df3 Clipboard: a paste after an unanswered read waits for its answer
When the check whether the clipboard still holds what VectorCraft copied,
or one of a paste's own reads, gets no answer within its 2 s, the read is
kept. The paste then waits for that answer on its background thread, up
to 10 s after the read was sent, instead of failing its other reads at
once and pasting the internal clipboard. When the answer is what
VectorCraft copied, or none comes, the paste takes the internal
clipboard; otherwise the clipboard is read as a paste reads it, with that
answer standing in for its read. An answer that came before the paste is
dropped and the clipboard is read again.
2026-11-11 15:49:27 -08:00
dotCooCoo 7f641b9c10 Help: a stalled interface writes a hang report, and Copy Troubleshooting Info copies it
When the interface thread stays in one part of a frame for 3 s, a
watching thread writes a hang report to the log and to
logs/hang-report-<process id>.txt. The report gives the part of the
frame (input hook, logic, interface, or the renderer after a frame in
which any window had input), a system clipboard call in progress, the
last 8 different command ids, the last 16 frame times, the platform,
window system, desktop and session type, Flatpak, graphics adapter, the
present mode and frame latency the app asks for, the running time and
the number of open documents. It holds no document contents, file paths
or command parameters. The interface thread marks its stages with a few
atomic stores a frame, and the watching thread reads those marks without
waiting on it.

The process keeps the report file locked until the interface answers
again, then removes it. A file nobody holds at a later launch was left
by a session that was closed while it did not answer: the launch writes
the report to the log, moves the file to logs/hang-report.1.txt and,
unless another start-up message is showing, says so in the status bar.
Help › Copy Troubleshooting Info puts the platform facts, the recent
commands and frame times and both sessions' reports on the clipboard for
a bug report. An in-line file dialog, an open menu of the macOS menu bar,
and the time after a frame that minimizes or hides the window or starts
moving or resizing it are not timed.

The menu label and the two status messages have rows in every catalog.
2026-11-11 15:19:35 -08:00
dotCooCoo 78f412f0a3 Clipboard: a paste's bitmap read waits for the owner off the UI thread
A paste on Linux and the BSDs read the bitmap on the clipboard worker but
waited up to 10 s for it on the UI thread, so a bitmap from an app that
never sent its data froze the window long enough for the compositor to
offer to close it.

The paste now sends the bitmap read to the worker and returns at once;
its background thread waits up to 10 s for the answer and converts it to
PNG. While that read is open, other reads fail at once instead of
queuing behind it. Each read gets its own answer channel, so a late
answer is dropped. The check of whether the clipboard still holds the
app's own bitmap waits 2 s at most, as text does.
2026-11-11 14:57:01 -08:00
dotCooCoo e3093034ea Scripts: opening a macOS menu reads the Scripts folder again
With the macOS menu bar, File › Scripts was read only at startup and
when the window became active, so a script added while the window
stayed active did not appear. The native menu now reports a menu
opening (Event::Opened, when AppKit begins tracking), and
native_menu::run reads the folder again, as opening the in-window File
menu does. Menu updates wait until tracking ends, so the new listing
shows the next time the menu opens.

Docs: docs/mcp.md (File › Scripts), docs/target-app-parity.md.
2026-11-11 13:47:41 -08:00
Ahmed Gomaa f0e50437c2 Save on a read-only location offers Save As
A plain Save that the location refuses (read-only filesystem or permission denied) now opens Save As with the name filled in, instead of ending in an error dialog. The refusal travels as a typed engine error (READ_ONLY_LOCATION), so the control protocol and MCP still return an error and never open a panel. Recovery failures, explicit destinations, a busy picker and Close/Quit keep their existing flow.

Closes #6146
2026-11-11 23:16:03 +02:00
dotCooCoo 825620eb6c Clipboard: Linux and BSD reads wait 2 s at most for the app that copied
arboard's Wayland data-control read waits for the app that owns the
clipboard to send its data with no time limit, and its X11 read waits up
to 4 s for each format it tries. These reads ran on the UI thread: a
Copy or Cut checking what the clipboard held, a paste, and the paste
check once its background thread is gone. A clipboard owner that never
sent its data froze the window.

On Linux and the BSDs, arboard's reads now run on a worker thread with a
clipboard handle of its own. Text and file lists wait 2 s at most and a
bitmap 10 s; the core-protocol fallback's text reads already wait 2 s.
While a read is unanswered, later reads fail at once. Writes stay on the
UI thread's handle.

The core-protocol fallback's worker is now generic and built on every
platform. On X11, closing the clipboard within 25 s of a read that got
no answer waits for that read to end, so the app's own handle is the
last one and hands the copy to the clipboard manager. On data-control
and the core protocol, closing does not wait for an unanswered read.
2026-11-11 12:06:33 -08:00
dotCooCoo 5ac7d97d85 Guides: ruler guides are document objects on their layers
Ruler guides were a list kept beside the layers. Each guide is now an
object of its layer or sublayer, always directly in it and above the
layer's art. These behave as on main:

- Guides draw on screen only. Exports (SVG, PDF, PNG, PSD), Fit All,
  Select All, the art bounds, clicks and marquees, and a layer's
  Pathfinder and Transform effects leave them out. The Layers panel
  lists them as guide rows of their layer, the highest guide.list
  index first.
- Deleting a layer deletes its guides, and merging layers keeps their
  guides in the merged layer.
- The guide commands number guides as guide.list does, in the order
  they were made.

New: each guide takes an id from the document's object ids. An object
command given a guide's id fails with an error, and node.move cannot
put a guide into a group or out of its layers. A guide made while an
opacity mask, a symbol or a pattern is edited moves to the top
visible, unlocked layer when editing ends.

File format: native files still save the guides in the document's
guides list, in every file version, so older builds read them. Each
entry may now also carry the guide's id, name, locked and hidden
flags; older builds ignore those fields. Opening a file puts each
saved guide on its layer (on the top visible, unlocked layer when the
file names none or a layer it does not have), and each saved guide
counts against the object limit for opening a file. A ruler guide node
that a file holds below a layer's art moves up to the layer's guides,
and one anywhere else (in a group or another object, beside the
layers, or in a symbol) is removed. Ruler guides read from an .ai file
become guide objects on the layer they were on, numbered in the order
the file lists them.
2026-11-11 09:52:28 -08:00
dotCooCoo 52efba54aa Scripts: File › Scripts lists the Scripts folder, subfolders as submenus
File › Scripts now lists the .js and .jsx files of the Scripts folder next
to the preferences, each named after its file without the extension, with
each subfolder as a submenu, above Check Script… and Other Script…. The
help page describes this listing:
https://helpx.adobe.com/illustrator/desktop/automate-visualize-data/automate-actions/install-and-run-scripts.html

Choosing a listed script runs it through script.run without the warning
Other Script… shows. script.listInstalled returns the same listing, and
ui.runInstalledScript {path} runs one entry.

VectorCraft's own rules: the folder is read off the UI thread when the
app starts, when its window becomes active and when the File menu of the
window's menu bar opens; only names are read; links, junctions, hidden
and system entries are left out and checked again before a run; one read
stops at 2,048 entries, 512 scripts, 128 subfolders, 4 levels or 250 ms
and the menu then notes that some scripts were not listed. Under an
automation read root, script.listInstalled and ui.menu.list leave out a
folder outside the root.

#1183 (LloydNicholson) also proposed a Scripts menu listing a folder.
2026-11-10 17:46:36 -08:00
Sven Lafebre eadf64fbab Fix #6335: Color Settings are remembered across restarts
edit.colorSettings set only the process-wide colour settings, so the RGB and
CMYK working spaces, intent and black point compensation went back to the
defaults at every start, although the profiles color.loadProfile loads are
kept (#2168, #2174). The engine now writes them to a settings file when they
change (Session::attach_color_settings), and the desktop app and
vectorcraft-cli keep that file as `Color Settings.json` next to the
preferences, attached right after the profile store so a saved working space
may be a loaded profile. Saved settings that can't be used (a profile that is
gone, a damaged or oversized file) leave the defaults with a log record, and
the next change writes over them. Nothing is read or written with
VECTORCRAFT_NO_PREFS.
2026-11-10 21:28:07 +01:00
dotCooCoo 7b44ef5737 Merge main into feat/script-run 2026-11-09 23:43:37 -08:00
dotCooCoo cc03fade6e Scripts: the growth budget counts every art store, with CLI and source fuzz tests
A document a script opens now counts the art in its graph designs and in
the original of the pattern being edited toward the growth allowance.
`Document::art_roots` and `art_roots_mut` list every tree of a document's
art; `any_node`, `edit_nodes_where` and the script's object count use them.

`script.run` checks the depth of `args` without recursion before it copies
or writes them out, so `args` nested 10,000 levels deep is refused with the
place it went past 64 levels instead of overflowing the stack.

New tests: graph-design art and the growth allowance, `args` nested 10,000
levels deep from a script (a RangeError) and from a caller, `run --cmd
script.run` on the command line with a report and with a thrown error, and
a property test that sends arbitrary source through `script.run`.
2026-11-09 22:00:04 -08:00
dotCooCoo 9ccea9cfcb Commands: engine.apiReference returns the command API reference in Markdown
engine.apiReference {} -> {markdown} writes a reference from the built-in
commands' parameter schemas each time it runs: a section per command that
has a schema, in registry order, with its label, menu path, API levels,
what it writes, cost, summary and return, and a table of its parameters
(type, range with included or excluded ends, unit, JSON or worked-out
default, required, levels and description; object members as dotted
rows). Commands without a schema, plug-in commands included, are left
out. Schema text is escaped so it stays plain text in its cell, control
characters become spaces, and a reference past 1 MiB is an error rather
than a cut-short text. The command needs no document.

MCP serves the same text as the fixed resource
vectorcraft://commands/reference (text/markdown; charset=utf-8); the
other resources still read as JSON.

The command's own schema raises the schema API level to 2. Its label and
its size error have rows in every catalog that needs them.

Docs: docs/mcp.md, docs/target-app-parity.md.
2026-11-09 21:24:13 -08:00