Commit Graph

3 Commits

Author SHA1 Message Date
r-zakarya ec8b5b3410 feat(android): a shield instead of a padlock, and the launch screen matches
The padlock was drawn in thin blue strokes on slate: at 36 px the outline muddied and the shackle vanished. A filled white shield with a punched keyhole keeps its silhouette at every size, and says protection more plainly.

The keyhole is CUT OUT rather than painted, through an even-odd fill on a single path - painting it meant keeping two files agreeing on one colour, and any drift would have read as a smudge. The launch layer is the exception: it sits flat on the system background, where a cut-out would be a hole, so there the keyhole is painted and stays entirely inside the white shield.

The launch background takes the top of the app gradient instead of slate, so the launch screen dissolves into the first screen rather than cutting against it. No gradient inside the vectors: the aapt this chain uses does not know inline gradients.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 00:02:27 +01:00
r-zakarya 8f9ebb8d47 feat(android): blue instead of cyan, everywhere at once
Cyan came from the desktop app. On the phone the reference is the system: its global search and its own apps are blue, and an app should look like the place it runs.

Accent #3B82F6 on the same slate, with white on the accent since blue is darker than cyan. The launcher icon and the launch screen follow - a cyan padlock in front of a blue interface would have read as a different app.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-15 19:55:06 +01:00
r-zakarya fdeb870541 chore: track the launcher icons, the blanket *.png rule was swallowing them
The rule exists for screenshots dropped in the repo root during dev. Launcher icons are content: they regenerate from make-icons.ps1, but tracking them means not having to know that - nor depending on System.Drawing to build an APK.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-15 16:12:08 +01:00