v0.1.2

Nothing in the app changes. If you are on 0.1.1 you are already running this.

This release exists to prove one step. The pipeline that publishes it now creates its own tag, at the
end, only once everything before it has passed — and that is the one step a dry run cannot exercise,
because skipping it is what makes a dry run dry. It is also the step that failed on v0.1.1, after the
tag had already been pushed and frozen. So the first thing put through it is a release that changes
nothing, where failing costs nothing.

Why the order changed

Pushing a v* tag used to start the build. That made one action mean two things: the request to
release, and the promise that a release exists. The promise landed first, on a ref that cannot be
moved or deleted.

v0.1.1 spent one on a run that died at its last step — the build, the signing and the packaging had
all passed, and a shell syntax error killed it there. The tag was frozen at a tree whose own pipeline
could not parse, so it could be neither moved onto the fix nor deleted, and the release had to be
finished from a branch instead.

before   push tag ─→ build ─→ sign ─→ package ─→ Release
         └── promise made before anything was checked

after    dispatch ─→ build ─→ sign ─→ package ─→ tag + Release
                                                 └── created together, at the end

A failed run now leaves no tag, no Release and no spent version number.

What else came out of that

• A dry run. The whole pipeline — both architectures built, signed, packaged, checksummed —
  stopping before the tag.
• No run had ever produced an artifact. Everything this workflow uploads lives under .release,
  and a leading dot makes it hidden, which the upload action skips by default while still reporting
  success. The build log the handbook tells you to open when a release fails had never existed. The
  first dry run found it.
• CI parses every workflow's shell. A run: block is only checked when it runs, and nothing but
  a release runs the release workflow, so an unterminated quote sat behind every green CI run until a
  real release found it.

The documentation describes an app that exists

A large power feature — two rendering backends, occlusion measurement, automatic still detection —
was built and then removed, 811 lines. The code went; the descriptions of it did not. The two lead
bullets of the README described measuring how much of the wallpaper is visible and photographing
pages that hold still. Neither had existed for some time. The same claim about test coverage was
written in six files.

Also corrected, each because it sent somebody somewhere wrong:

• Installing needs three commands, not two. The cask has a postflight block, so Homebrew
  refuses to load it untrusted. The install block on the v0.1.1 page was missing brew trust — anyone
  following it hit a refusal. It is on this page, and in the cask's own comments.
• The framing interaction was rebuilt in 0.1.1 and the README still said "drag a rectangle over the
  wallpaper".
• Twelve entries in the upstream-issue triage were written as pending plans for work that has
  shipped, including a page per display and the playlist.
• 25 strings no code referenced, 13 of them for the deleted feature, were still in the app's
  localization catalogue.
• Four issue templates asked reporters to paste a line the app has never emitted.

Known issues

Unchanged from 0.1.1, and tracked in
docs/ROADMAP.md:

• A YouTube video cannot be shrunk back into the YouTube page, so there is no way to sign in.
  Bilibili does not have this problem.
• Switching website can take a few seconds, with no sign that anything is happening.
• Nothing is done yet to reduce what the app costs while nobody is looking at it.
• The app follows the system language; there is no picker inside it.
• The app cannot tell you a new version exists. brew upgrade — or this page — is how you find out.
• Nothing anywhere handles HDR.
• Multiple displays has never been run on two.

Requires macOS 15 or later.

---

Install

brew tap PathGao/tap https://github.com/PathGao/Nifro
brew trust --cask PathGao/tap/nifro
brew install --cask nifro

The middle line is not optional. Homebrew refuses to load a cask from outside its own
repositories until you say you trust it, because a cask can run code after installing.
This one runs a single command — it clears the "downloaded from the internet" mark macOS
puts on the app. Read it first: https://github.com/PathGao/Nifro/blob/main/Casks/nifro.rb

Already installed with Homebrew: brew upgrade --cask nifro.

Or download the disk image

Nifro-arm64.dmg on Apple silicon, Nifro-x86_64.dmg on Intel. There is no universal binary, so
nobody downloads the half they cannot run.

This build is self-signed and not notarized by Apple, so a disk image you download and open yourself will be turned away the first time with "Apple could not verify Nifro is free of malware". That dialog offers only Move to Trash and Cancel — the way through is somewhere else:

1. Press Cancel. Do not move it to the trash.
2. Open System Settings → Privacy & Security and scroll to the bottom.
3. There is a line naming Nifro, with an Open Anyway button. Press it, and confirm with your password or Touch ID.
4. Press Open in the last dialog. macOS remembers, and never asks again.

Installing with Homebrew skips all of that — the cask clears the mark for you.

Checksums

Apple silicon  Nifro-arm64.dmg   sha256 79dad42713e221270d400a1c76b3908455e0b889a9eb4bc135557e1827466b6e
Intel          Nifro-x86_64.dmg  sha256 049e58d99b46c15ee516de53d2616369386a2f50aa6607d7d48af4c019faa23a

---

What's Changed

• The release step could not be parsed, so v0.1.1 has no Release by @PathGao in #4
• cask: bump to 0.1.1 by @github-actions[bot] in #5
• The tag is created by the release that succeeded, not by the request to start one by @PathGao in #6
• The documentation describes an app that exists by @PathGao in #7

New Contributors

• @github-actions[bot] made their first contribution in #5

Full Changelog: v0.1.1...v0.1.2