Modernize the deleted-file icon lookup

[tagliala]

Proposal

Draft pending maintainer confirmation of the deleted-entry glyph. This replaces the legacy empty/dashed missing-object placeholder with a generic document icon. Please confirm that this visual change is appropriate before marking the PR ready.

Use -[NSWorkspace iconForContentType:UTTypeData] for the deleted-state icon in Frameworks/TMFileReference/src/TMFileReference.mm, replacing the deprecated HFS-based iconForFileType: lookup.

One line, reusing the generic-file fallback and UniformTypeIdentifiers import/link already present in the same class. Git status handling, red deletion badge, caching, modified opacity and callers are unchanged. Deleted entries remain generic rather than extension-specific.

This is not a pixel-equivalent API substitution or a claim that the old lookup returns no image. The old missing-object outline is visible in light mode and faint in dark mode; the proposal draws a document with the same red badge. The screenshots below show that tradeoff.

Refs #118: one of the six deprecated icon lookup sites, not the complete icon-family migration. Independent of #122–#125.

Before and after

Actual built app, same synthetic Git project and 1040×680-point viewport. Six deleted file types: .txt, .md, .py, .json, .png and no extension. Added, modified and unchanged files provide controls.

Appearance	Base 4fc23bc6	Proposed 870f42d3
Light / Mac Classic
Dark / Twilight

Captures contain synthetic data only, were optimized with optipng -quiet, and are attached rather than committed. Images are hosted against the contributor's public fork. The previous app/session and macOS appearance were restored after capture; no installed app or user project was modified.

Verification

Local checks on Apple Silicon, macOS 27.0.1:

• Release arm64 TextMate builds on base and final: passed; TMFileReference.mm recompiled without its previous iconForFileType: warning.
• FileBrowser and OakTabBarView suites: both pass before and after.
• Strict deep signature verification and git diff --check: passed.
• Assert-based probe compiled from the actual baseline/final TMFileReference source, with project flags, assertions enabled and real badge resources: both pass. Checks expected background/badge composition, cache reuse/invalidation, same-status caching, modified opacity and status-cleared fallback. Light/dark rendering at 16/48pt and @1x/@2x.
• Visual inspection of the real app: all six deleted types use the generic document with the red badge; control rows retain their glyphs/badges in both appearances.

The probe constructs its expected image using the corresponding background API, so screenshots establish the actual glyph. The full project suite, other macOS versions and a contributor-performed functional regression test were not run. Local checks are not remote CI results.

Independent review

Read-only Pi review of 870f42d3 through Anthropic directly: no introduced blockers. The reviewer traced the class, SCM providers/consumers, existing type/linking convention, SDK availability, probes and original screenshots. The API is available since macOS 11, below the 14.0 deployment target. They executed no verification and did not review the later six-type/light-mode captures; the source and reviewed diff are unchanged.

Prepared with AI assistance. Please independently review both the migration and the proposed visual policy. This code-only review is not a CI-backed merge approval.

AI reviewer: anthropic/claude-opus-5-5 · reasoning: high

[dayglojesus]

@tagliala I like the update, but thought I might take a stab at something that sticks with the original per-file glyph
#129

Let me know what you think.

[tagliala]

Hi @dayglojesus , thanks! I think that the dimmed version is the way to go

I close here as superseded by #129