v0.61

Sabine 0.61

• On Linux outside an app sandbox, Sabine holds an app to its [sandbox] declaration with Landlock
  and a system call filter, without root or bubblewrap: its files, devices, TCP network, abstract
  sockets and signals, for the app and every process it starts. See
  App sandbox.

v0.60

Sabine 0.60

• On Linux, windows survive a crash of the Wayland compositor when the desktop starts it again on
  the same socket, as Luft's Kestrel and KDE Plasma do: they reconnect and come back with their
  page as it was. Chromium gets a Wayland display of its own in the Sabine host, so the browser and
  its pages keep running while the compositor restarts. See
  Compositor restarts.

v0.59

Sabine 0.59

• A Sabine update never stops an installed app from running. When a release no longer accepts the
  build of an app on the machine, including apps installed for every user, Sabine holds it until
  those apps update or are removed and installs the newest earlier release meanwhile.
  held_system_update() reports what is waiting and for which apps; sabine update and
  sabine-service maintain print it.
• Bundles record the Sabine build they were made with as sabine in their manifest's [app] table.
• sabine-service check-apps fails when the Sabine it belongs to would not run an app installed for
  every user, for operating system image builds.

v0.58

Sabine 0.58

• Apps declare what they need from a sandbox in a [sandbox] table in Sabine.toml: network,
  filesystems, devices and the session bus names they talk to, in Flatpak's terms, or
  unsandboxed = true with a reason. sabine dev and sabine bundle check it, and every bundle
  carries it in its manifest, so a store or the system can show and enforce it before the app
  starts. See App sandbox.
• Only apps installed for every user, below /usr/lib/sabine, share a Chromium with each other.
  Other apps get a shared runtime of their own, so a page can never reach into another app's
  browser process.
• Inside a Flatpak-style sandbox, apps run their own Chromium, started through Zypak when the
  sandbox provides it, so renderers keep Chromium's sandbox.

v0.57

Sabine 0.57

• Sabine writes a TypeScript client for an app's bridge commands and events, so the page and the
  app share one contract instead of copies kept in step by hand. Commands registered with
  bridge_typed or bridge_typed_async, and events declared with the new bridge_event, go into
  the file [bindings] path names in Sabine.toml, as commands and events with the app's own
  types. Each type reads as the app sends it, and params as the app accepts them. bridge_type
  adds a type no command or event names, so shared page packages can have bindings too.
• bridge_typed and bridge_typed_async need params and results that derive specta::Type, next
  to serde's derives. Add specta = { version = "=2.0.0-rc.27", features = ["derive"] } to the
  app's dependencies.
• sabine bindings writes the file, sabine bindings --check fails when it is out of date, for CI,
  and sabine dev rewrites it before it starts the page. New apps from sabine new call their
  commands through it.
• Events declared as BridgeEvent<T> are sent with BridgeEventEmitter::send, and bytes events,
  BridgeEvent<Bytes>, with send_bytes.

v0.56

Sabine 0.56

• Merge pull request #5 from Lantharos/claude/laughing-mccarthy-0v3wo5
• Paint square corners and keep the setting in step with new windows
• Let apps square their window corners while they float

v0.55

Sabine 0.55

• Render the runtime probe with SwiftShader on Linux
• Fix Sabine apps on Linux whose window never appeared when Chromium couldn't hand the page over in GPU frames, such as when it couldn't allocate the buffers it shares them in or painted without the GPU. The window kept waiting for GPU frames: it starts its own graphics device only once the compositor shows the first of them directly, and software frames need that device. When Chromium paints without the GPU, or the loaded page still has no GPU frame 2 seconds later, the window now starts its device and shows the page in software frames.
• Fix Sabine apps on Linux with AMD graphics never getting GPU frames. Mesa laid the buffers Chromium hands each frame over in out with delta color compression, which Chromium couldn't use, so no frame reached the window. Sabine's Chromium now runs with AMD_DEBUG=nodcc, added to whatever AMD_DEBUG the app was started with.
• The runtime check that runs when Sabine installs or updates Chromium renders its test page with SwiftShader on Linux. From CEF 156, Chromium renders nothing when its GPU process can't start, as on machines without a display, so the check failed and a working runtime was set aside.

v0.53

Sabine 0.53

• Sabine has an icon of its own, a navy swallow on an ivory tile. The window that prepares Sabine
  and the notices it shows when an app can't start carry it, and on Linux the Sabine service adds a
  hidden com.lantharos.sabine desktop entry and icon, for every user when Sabine is installed
  system-wide, so task lists and system monitors can show the shared Chromium as Sabine. On
  Windows the Sabine service carries the icon in Task Manager and Installed apps, and on macOS the
  shared host does in Activity Monitor. Apps keep their own icons, including on their update prompts.
• Pages print through the desktop's own print dialog. On Linux, window.print() and the new
  print.page() and print.element() ask the print portal how to print, lay the page out on the
  chosen paper and pages, and send it to the printer without asking again. macOS and Windows show
  the system's print dialog.
• print.files() prints PDF, image and text files as one document, and Rust code does the same with
  BridgeEventEmitter::print_files. On Linux PDF files go to the printer as they are, with their
  pages chosen in the print dialog, and images and text are laid out on the paper chosen in it.
• Windows setup no longer fills its log with a line for every moment of the Chromium download and
  unpacking. The setup log, and the output of sabine runtime install, sabine update and
  sabine-service ensure-runtime, record each step once with a percentage every tenth of the way
  and the result, while the progress bar of the .exe and MSI setup wizards follows the work
  smoothly.

v0.52

Sabine 0.52

• Fix Sabine apps failing to open on Linux with "The application could not continue" after the
  computer's hostname changed, as it does on laptops that take their name from the network, or
  after a crash or power loss. Chromium found the lock its last run left in the app's profile,
  took it for another computer using that profile and tried to ask in a dialog the desktop can't
  show. Sabine now clears a lock no running Sabine browser holds before Chromium starts, and a
  shared Chromium no longer takes an app's profile while the app's own Chromium still runs after a
  hostname change.

v0.51

Sabine 0.51

• Fix Sabine apps crashing as they quit on Linux, most often with NVIDIA's driver, sometimes
  reported as "double free or corruption". The window tore its graphics device down on another
  thread while the process was already exiting, so the driver freed its own state twice. The
  window now destroys its device before it exits, and quitting an app ends it with status 0.
• An app stopped with SIGTERM or SIGINT, such as by a system monitor or systemctl stop, ends
  by that signal instead of exiting with a status, so whatever stopped it sees that it did.
• Tapping or clicking into a text field on Linux asks the desktop for its on-screen keyboard.
• An app no longer claims the shared Sabine host is out of date when another copy of the app,
  running with another version of Sabine, has its data open. The window says so and asks to close
  the other copy, and says the app needs another version of Sabine only when its own host doesn't
  match. A shared Chromium left over from another Sabine build hands the window to the app's own
  Chromium, and a browser connection that breaks while it starts is retried.