diff options
| author | srdusr <[email protected]> | 2026-07-04 14:22:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-07-04 14:22:00 +0200 |
| commit | d448a82990efb5c510064f1de5b5d32e932a4f9e (patch) | |
| tree | f74f66522f8259a2e726f2b892ede8332667e74b /docs/DEFAULTS.md | |
| parent | 4c6d059359537e03f677e83d345f52fae29ae746 (diff) | |
| download | srdwm-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.md | 23 |
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. |