Syzygy 1.1.0: rebuilding the desktop as a real workbench

Syzygy 1.1.0 is still in development. The defining work in this release is not another isolated feature. We rebuilt the desktop shell, navigation, explorer, document pane, preview surfaces, popup windows, and settings routes as one workflow, then connected commands, editing, recognition, and sync state to that workflow. You open one workbench and see the actions that fit the selected item.

#What actually changed

Before 1.1.0, the desktop could complete the same task through several entry points, but each surface carried its own layout and context rules. Moving from a list to a preview or from an editor back to history could require a second search. Background downloads could make a foreground command feel unavailable. This release addresses the structure behind those symptoms: keep the item and its context stable, then expose the relevant capability beside it.

#A desktop workbench rebuilt from the shell outward

#A continuous workflow instead of unrelated pages

The new shell puts the left rail, current page title, content area, and auxiliary panels in one hierarchy. The main navigation selects a work area, the page title identifies the object in that area, and the return action goes back to a known context. Clipboard, devices, settings, and account surfaces no longer invent separate title-bar and spacing conventions. Popup layers follow the same hierarchy.

This reduces the amount of state a user has to remember. Open a document from clipboard history, edit it, save a new snapshot, and return to the list: the previous selection and filter still have a clear place. The UI does not need to put every action in one window, and the runtime does not need a hidden duplicate state to keep the flow alive.

#The explorer split keeps the item in view

The clipboard explorer can now combine a list, a document pane, and an inspector in a stable split layout. The list is for scanning, the document pane is for the selected content, and the inspector keeps item actions and metadata nearby. When the window narrows, lower-priority panels collapse; when it expands, the selected item remains the same.

The split is content-aware. Text belongs in the document pane, images belong in a preview surface, and a file first exposes its name, size, type, and local availability. The layout follows the content capability instead of forcing every item into one card shape.

#Quick panels and popups have a clear boundary

The quick panel received a larger, calmer layout so long titles, preview actions, and keyboard hints do not compete for the same pixels. Floating panels and popup windows now share surface, opacity, and title-bar rules. They feel like a temporary extension of the workbench rather than a separate application.

Native window opacity and web-content opacity are separate controls. Changing the window surface does not unexpectedly fade the page content. Vibrancy and platform corner treatment are applied only where the platform supports them; the workflow does not depend on decoration.

#Commands and shortcuts follow the workbench model

#The latest command appears first

The command palette now stores the most recently successful command. The next time you press Command + K, or the platform equivalent, that command appears at the top and can run with Enter. The palette records the command identity, not clipboard text, and a failed search does not become the latest command.

The change removes a repeated search step from common work. Previewing an item, copying it, opening the text workbench, or viewing device diagnostics starts from a useful first row while the full command search remains available.

#Shortcut configuration matches desktop behavior

Shortcut settings now edit the key combination, scope, current binding, and conflict state in one flow. When focus is inside an input, dialog, or quick panel, the current surface gets first handling. System takeover only applies after the user enables it.

Windows surfaces report the state of system shortcut takeover and cover the Figma capture case. You can see which keys Syzygy handles and which keys remain with the operating system. A dedicated setting turns takeover off without requiring an application restart.

#Foreground commands keep their priority

Enter, copy, and open are foreground commands in the quick panel. Large project downloads, remote-image materialization, and sync catch-up run in the background. They can update progress, but they cannot take the selected item away from the foreground action. Closing the panel does not cancel a queued task; reopening it reads the same task state.

#A text workbench that keeps the source in reach

#Preview, edit, and save share source information

The text workbench now handles semantic hypertext markup language (HTML). Headings, paragraphs, lists, quotes, and code blocks keep their structure between preview and editing, so a document does not need to be flattened into one plain-text blob before it can be changed.

The editor adds search, replace, history, and explicit save state. Saving creates a new content snapshot and records the source application while preserving the original clipboard item. You can use the edited result without losing the content that was copied first.

File preview checks whether the complete local bytes exist before presenting byte-dependent actions. A metadata-only file can show its name, type, and size, while open, copy, and edit wait for materialization. The action surface follows the real state instead of discovering the missing download after a click.

#Capabilities, not filenames, choose the action

The content capability model now spans preview, copy, edit, search, and recognition. Text, images, files, rich content, renderable graphics, and derived OCR results declare what they can do. One item can offer both text editing and image rendering; the current action selects the appropriate representation.

This prevents a renderable vector graphic from being reduced to “just an image.” The original content stays available, while the preview uses a representation that is useful to read. An application that needs the real file still receives verified original bytes.

#Better recognition, remote images, and OCR

#File classification uses more than an extension

Recognition combines content type, filename, extension, and readable body text to classify an item. Preview and search can distinguish plain text, images, documents, PDF files, and renderable graphics. If classification is uncertain, the original file remains unchanged.

#Local, HTTP, and HTTPS images share one boundary

Image addresses in HTML are decoded before the application validates local paths, HTTP URLs, or HTTPS URLs. A preview can show a remote image. When the target application needs bytes, Syzygy downloads the image, checks the response and content, and only then writes it to the clipboard. A failed download leaves the existing clipboard untouched.

SVG and other renderable graphics keep both the original text and the rendered image. You can read the graphic, create a text snapshot, or request a real image when the target requires one. Redirects, allowed hosts, and resource budgets remain explicit application boundaries, and diagnostic output excludes image bodies and account secrets.

#OCR language candidates are easier to understand

OCR now groups candidate results using language hints. The image sheet shows the active language range and candidate groups, and derived text remains linked to its source image. Re-running recognition or deleting a result does not overwrite the original image.

#Sync progress is part of the item state

#Large transfers show real progress and speed

Clipboard sync distinguishes queued, transferring, verifying, and ready. When the transport provides measurements, the interface shows received bytes, total size, and current rate. When a total is unavailable, it says so instead of inventing a percentage.

queued -> transferring -> verifying -> ready
                    |                 \\
                    +-> bytes, rate, and current state

The list, detail pane, and preview read the same progress state. Switching surfaces therefore does not produce three different answers. While a background transfer runs, the foreground remains available for search, tagging, copy, and open actions.

#Network diagnostics explain where time went

The device surface can show the selected route, remote address, local address, connection reuse, candidate probes, retry count, and stage timings. A diagnostic dialog produces a redacted report that can be copied without clipboard content, passwords, or access keys.

Selected route means the connection that carried the session. It is not inferred from an address prefix. A direct session may use a VPN address, and a relay can be faster than a direct candidate that repeatedly fails. The diagnostic view keeps route selection and address type separate so a support report can answer a real question.

#Tags, trash, and account state stay consistent

Tag pages, item rows, and preview columns now read one persisted tag color. Trash operations keep a recoverable-first flow, and retention and deletion state use the same data in list and detail surfaces. Account pages, device authorization, and entitlement state share the server-confirmed result, so a refresh does not make separate pages disagree.

These are not isolated 1.1.0 marketing points. They describe the boundary of the redesign: the surface can change, but the authoritative item state must not drift between pages. An action completed in one place should have the same explanation everywhere else.

#From 1.0.1 to 1.1.0

1.0.1 focused on stable distribution, clearer entitlement duration, and quick-panel session behavior. It made existing paths easier to reproduce. 1.1.0 builds on that stability by rearranging the desktop information hierarchy and placing editing, recognition, sync, and diagnostics in one context model.

The two releases solve different layers of the same problem. 1.0.1 reduced uncertain outcomes. 1.1.0 reduces the steps needed to understand and continue an outcome.

#Status and upgrade notes

This entry describes the 1.1.0 development line. Public installers will follow the build, test, and deployment artifacts that pass release verification; a development surface is not a promise that every platform has shipped at the same time.

Users on 1.0.x can continue using existing history and paired devices. After upgrading, the workbench redesign does not reinterpret original items, tags, trash state, or sync policy. Remote images and large files still materialize locally when an operation needs real bytes, and diagnostic reports remain redacted.

The acceptance criteria are concrete: the workbench should tell you where you are, a selected item should tell you what you can do next, a background transfer should tell you how far it has gone, and a slow session should tell you which diagnostic stage to inspect. When those four answers stay visible, the redesign is doing its job.