srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/crates/wayland/src/decoration/font.rs
AgeCommit message (Collapse)AuthorFilesLines
2026-07-07Lock screen: show each key's alternate character, use a UI font, space the dotssrdusr1-0/+67
Three reports, three separate causes. Alternate characters were invisible. A keycap drew only the character the current shift state types, so there was no way to find a symbol without pressing Shift and hunting for it - a physical key is labelled with both. Each cap now draws the other state's character small and dimmed in its top-right, skipped where the two are the same (every letter differs only by case, which the cap already shows) and for named keys like Enter. "Enter Password" rendered in a monospace font. find_system_font deliberately prefers a mono face, which is right for a titlebar title or a menu row sitting in columns and wrong for a sentence; on this machine it resolves to DejaVu Sans Mono. New find_ui_font prefers a proportional face from a ranked list of widely-installed families, falling back to the mono one, and the lock screen's prose - prompt, clock, date, username, status -- uses it. Ranked rather than first-found so the result does not depend on directory order, which is how the mono scan once picked an italic face and rendered every titlebar in italic. The password dots had no spacing. They were drawn as a plain string, so a run of identical bullets separated only by their own advance read as one smeared blob rather than countable characters. Added explicit tracking, excluded from the centring width so the row does not sit half a gap left. 531 tests pass, clippy clean.
2026-05-11Three live bug reports after a restart: icon drag, lock cursor, lock boxsrdusr1-0/+54
All three reported directly after the owner restarted into today's build. Desktop icons could not be dragged at all in single-click mode. The press handler opened the icon immediately when general.desktop_icon_single_click was on, so the branch that starts a drag was unreachable and an icon could never be moved. Deciding activation on press cannot distinguish a click from the first instant of a drag. Every press on an icon now starts a potential drag and release decides which it was, using a 4px movement threshold that latches once exceeded. Double-click mode goes through the same path, so both modes now drag identically. The lock screen drew no cursor. The cursor push in the udev render loop sits inside `if !locked`, and a locked head renders only the lock element list, so nothing drew a pointer - and on a bare TTY nothing else does. The on-screen keyboard's clicks were being handled correctly the whole time (native_lock_click); they simply could not be aimed. The pointer is now prepended to the lock element list, above the UI it is used to click. The password field's opaque panel is gone. New LockConfig::box_opacity, default 0.0: no fill, no border, no rounded rectangle, just the dots and status text over the blurred background. Raising it restores the panel at that opacity for anyone who wants a solid field. Drawing text on a transparent surface needed a new blit_glyph_over: the existing blit_glyph blends against one flat opaque colour and writes alpha 255, which would have turned every glyph into a block of the assumed background - the same box with its middle removed. VERIFICATION STATUS, stated plainly: all three are code-complete and the suite passes, but none is confirmed on screen. The nested backend's capture pass does not draw the desktop icon grid (a gap already recorded in winit/capture.rs), so the icon drag cannot be checked by screenshot there, and aiming blind is what this project's own rules forbid. The two lock changes were not visually checked either. 515 tests pass, clippy clean.
2026-01-30Fix a real regression: dynamic-mode windows lost their shadow via ↵srdusr1-0/+12
toggle_floating The tiled-shadow-tint fix earlier today gated the shadow on Window::floating alone. arrange_workspace only reads floating under the "tiling" layout, so every window on this project's own default "dynamic" layout starts, and stays, floating: false - the gate misread that as "tiled, no shadow" regardless of which layout was actually running, so shadows silently vanished under dynamic mode entirely, recoverable only by pressing Super+S (toggle_floating), which then looked like that key toggles a tint rather than floating. Fixed by checking the workspace's own layout name first: a window is only "currently tiled" when its workspace runs "tiling" AND it hasn't opted out via floating. DecorationSignature's floating field is now currently_tiled, since a layout switch changes this for every window on a workspace without touching any of their own floating fields. Also disabled general.shadows in the user's own config per direct request - never asked for, on by default, and a real problem for color-accuracy work regardless of how correctly it renders otherwise. Also fixed both context menus (titlebar and desktop) silently truncating labels past a fixed 170px width with no indication - widened dynamically to each menu's own real widest label via a new measure_text_width helper.
2025-02-15Checkpoint: preserve all uncommitted rust-rewrite worktree worksrdusr1-0/+146
Safety commit before reconciling this worktree with main, which has diverged with its own separate fixes today. Nothing here is reviewed or curated yet - this exists purely so none of this work can be lost to a git operation, disk issue, or worktree cleanup while that reconciliation happens.