srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/docs/DEFAULTS.md
diff options
context:
space:
mode:
authorsrdusr <[email protected]>2026-07-04 14:22:00 +0200
committersrdusr <[email protected]>2026-07-04 14:22:00 +0200
commitd448a82990efb5c510064f1de5b5d32e932a4f9e (patch)
treef74f66522f8259a2e726f2b892ede8332667e74b /docs/DEFAULTS.md
parent4c6d059359537e03f677e83d345f52fae29ae746 (diff)
downloadsrdwm-d448a82990efb5c510064f1de5b5d32e932a4f9e.tar.gz
srdwm-d448a82990efb5c510064f1de5b5d32e932a4f9e.zip
Use the real user avatar on the lock screen, and let its keyboard type every character
Two gaps, both found by being asked about them. ~/.face was never read. The file exists here, a 300x300 JPEG, and a grep for .face/AccountsService/avatar_path returned nothing anywhere in the codebase: the lock screen drew a coloured circle with the user's initial unconditionally. It now looks for ~/.face, ~/.face.icon, then /var/lib/AccountsService/icons/$USER, which is where GNOME and KDE keep the picture their settings UI sets. Scaled to cover the circle and centre-cropped rather than letterboxed, and masked with a soft edge. Falls back to the initial when nothing is set or the file will not decode. That needed a raster decoder, since ~/.face is JPEG and the only image code here was resvg, which is SVG-only. Added image with default features off and only jpeg and png. The on-screen keyboard could not type most passwords. It had letters, digits, and the digits' own shifted symbols, and nothing else - no -, _, ., /, =, [, ], ;, ', comma, backslash or backtick. For the case that keyboard exists for, a session with no reachable physical keyboard, a password containing any of those meant no way in at all. Every printable ASCII character now has a key, with a test asserting the whole 0x20..0x7f range rather than spot-checking. The lock screen itself could not be screenshotted: locking a nested instance hits the pre-existing EGL context-loss crash already recorded in docs/TODO.md, confirmed again here. That is environmental and predates this change, so the on-screen appearance still needs the real session. The avatar path is covered by four tests including one that decodes the real ~/.face through the same function the lock screen calls. 529 tests pass, clippy clean.
Diffstat (limited to 'docs/DEFAULTS.md')
-rw-r--r--docs/DEFAULTS.md23
1 files changed, 23 insertions, 0 deletions
diff --git a/docs/DEFAULTS.md b/docs/DEFAULTS.md
index 014c6f5..ded5b03 100644
--- a/docs/DEFAULTS.md
+++ b/docs/DEFAULTS.md
@@ -1107,3 +1107,26 @@ own `chrome/` directory uses for `userChrome-traditional.css` versus
Firefox is a separate surface again: it draws its window buttons itself and
takes them from `userChrome.css`, which needs
`toolkit.legacyUserProfileCustomizations.stylesheets` set to `true`.
+
+## Lock screen: avatar and on-screen keyboard
+
+**Avatar.** The lock screen shows the user's own picture, looked for in the
+conventional places, most specific first:
+
+1. `~/.face`
+2. `~/.face.icon`
+3. `/var/lib/AccountsService/icons/$USER` - where GNOME and KDE store the
+ picture set through their own settings UI
+
+These are conventionally JPEG or PNG. The image is scaled to *cover* the
+circle and centre-cropped, not letterboxed into it, and masked with a
+one-pixel-soft edge. With no avatar set, or a file that cannot be decoded,
+it falls back to the coloured circle with the user's initial
+(`theme.lock.avatar_bg`).
+
+**On-screen keyboard.** `theme.lock.show_keyboard` (default on) draws a
+QWERTY layout for a session with no reachable physical keyboard. Every
+printable ASCII character is typable, shifted or unshifted - letters,
+digits, and all of ``-_=+[]{}\|;:'",.<>/?~`` plus space. A test asserts
+the full range, because a lock screen that cannot type some character in
+the password is a lockout rather than an inconvenience.