Workspace

The application implements a document-based user interface, where the type of document is called a Workspace.

Multiple tabs may be opened within a single Workspace window, each of which may be viewing/editing different parts of the same Workspace. "Open New Tab" therefore duplicates the current view of the workspace by default.

The content area of a Workspace window (within each tab if there is more than one), presents the Workspace's contents—(rich) text boxes, images, media clips, and so on, arranged spatially, and possibly augmented with additional "decorations" such as connecting lines—similar in a number of ways to web-based "virtual whiteboarding" services.

Each item contained within a Workspace may generally be either:

• Displayed as an icon — i.e., similar to how Finder might display a file, and must be double-clicked to open
• Displayed as content — the item’s content is rendered within a bounding box in-place

An item may be editable, or read-only, and item's position and dimensions may be modifable or fixed, depending upon both the item’s and the Workspace’s properties.

??? If an item is editable, then focusing it will cause a caret (or similar) and editing controls to be shown and edits made possible.

Items can be moved and resized by dragging where one would expect, ideally with drag handles displayed on hover, with the caveat that where an item is editable, the editor is the view that will receive drag events across the face of the item

It's possible to zoom whilst editing — i.e., cause the editor takes up the full content area of the tab.

Double-clicking an item has the same effect as focusing and then zooming, and so feels like you're "opening" it.

Initially the range of supported item types will be very short and restricted to those readily implementable with minimal effort on macOS (for example, a rich text editor that serialises as RTF).

As soon as is practically possible, all of the type-specific logic and UI should be to be devolved to separate rendering processes.

Workspaces are hierarchical. Folders within workspaces are always displayed as icons and so must be double-clicked to open them. Items can be moved into folders by dragging and dropping them. Folders are spring-loaded.

All interactions with a Workspace are accomplished via a cross-platform but macOS-savvy synchronous C++ API, Workspace Services, which represents the Workspace and different kinds of Item as C++ classes and provides intuitive methods for manipulating them. There is a suite of APIs to be invoked as a direct result of user interactions, for example to signal that the user focussed a particular item in a certain tab. There are a number of callbacks that will be invoked when external changes have occurred which must be reflected in the user interface.

On the filesystem, Workspaces are directories, and so "Packages" in Apple's document architecture. Each Workspace Item is either a file, or a directory containing files, depending upon the type of item. Workspace Services takes care of naming and locating the files within a Workspace.

Workspaces store both shared and per-user property-list-style metadata for both the Workspace itself and every item (including folders) within it, with per-user data overriding Workspace-shared data. These metadata include the visual presentation information, such as the dimensions and position of each item, and the overall Workspace colour scheme (which overrides the system accent colour and so can be used to visually distinguish different Workspace windows).

Workspaces include a Stationery library, whose contents become templates. Stationery can be created by dragging it into the Stationery library (which always creates a copy). Dragging something out of the Stationery library also creates a copy (by definition).

Workspaces are version-controlled, but the processes are managed automatically by the Workspace Services API.

Workspaces can be synchronised between hosts.

In addition to Workspace tabs, Browser tabs may be opened. Any number of Browser tabs may be interspersed with Workspace tabs. A Browser tab displays any arbitrary https: URL in a standard WKWebView . Browser tabs do not have any means to interact with the contents of a Workspace, however their state and history is stored within the Workspace.

The Workspace window includes a number of additional palettes, which exist outside of the tab view, some of which are visible and docked to the window's edges by default. These are:

• The Control Bar, by default docked to the left-hand side, and has a similar appearance to the toolbar in a design or drawing application, presenting a single vertical list of monochrome icons. The topmost icon, the cursor tool, is selected by default. In a Browser tab, this is replaced by the Bookmarks Bar, which shows a tree view of the Workspace-shared bookmarks.
• The Inspector, by default docked to the right-hand side, which shows a context-dependent information — similar to Finder's "Get Info"
• The Stationery palette, docked below the Inspector, which shows the contents of the Stationery library (as icons)
• The Location Bar, by default docked to the top, and provides "Back", "Forward" and "Home" buttons, and shows the current location within the Workspace. Its constitutent items are also spring-loaded. When a Browser Tab is focussed, the location is replaced with an address/search field and an additional "Refresh" button is visible.

Palettes may be un-docked and moved around or closed at will. In addition, a number of other palettes may be displayed and docked, but in particular an embedded Terminal palette (by default docked to the bottom when visible).

As with item renderers, palettes should be devolved to child processes as soon as is practically possible. At that point, both would represent extension points, and so in principle any number of item types or available palettes could be available.

The processes launched in the Terminal palette (and indeed, any child processes) inherit via the environment the location of a control socket managed by Workspace Services.

When a Workspace is opened, its complete state, including open tabs and scroll locations, is restored via the Workspace Services APIs.