fix(presentation): tool-specific cursor + Pen/Highlighter icons with outline pointing up-left#115
Merged
Merged
Conversation
The HUD toolbar changes the selected tool but the on-screen cursor remained a generic system cursor (or the default arrow), giving no visual feedback of which tool was active. Now setCursor() is called on tool change with a pixmap built from qtawesome icons matching the HUD. - Pen / Highlighter: cursor is the tool icon rotated -90 so the tip points at the click position (hotspot at bottom-left) - Eraser: qtawesome eraser icon with centred hotspot - Laser: BlankCursor (the red dot is drawn manually) - Pointer: default ArrowCursor via unsetCursor() The cursor rebuild is driven by dark_mode so it re-tints on theme switch (update_theme already calls _apply_cursor). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…irection The HUD row placed the mouse-pointer icon with its tip toward the bottom-left, but the Pen and Highlighter icons kept their default FontAwesome orientation (tip toward the bottom-right), which read as visually inconsistent. Both icons now go through a small rotation registry (_ICON_ROTATION) that applies rotated=-90 so their writing tips point in the same direction as the pointer arrow. The registry is honoured by both _refresh_icons (base render) and _refresh_active (per-state colour swap), so the rotation survives active-state toggles and theme switches. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The mouse pointer icon points up-left (standard cursor convention), but the fix from commit 2c23d14 used rotated=-90 which orientation didn't match. Adjusted to rotated=180 (paired with a top-left hotspot in the cursor) so Pen and Highlighter now visually align with the pointer's direction. Both the HUD icon table (_ICON_ROTATION) and the cursor helper (_cursor_for_tool) use the same value, and the cursor hotspot moved from (2, size-2) to (2, 2) so the tip of the tool anchors at the top-left corner of the cursor pixmap.
Commit 51bc941 used rotated=180 assuming it would flip the icon to up-left, but 180° is rotation (not flip) — it left the tip in the top-right corner. Pixel analysis of qtawesome renders confirms that rotated=90 (clockwise quarter turn) is what actually maps the native pen tip (bottom-right) to top-left, matching the mouse-pointer. Same value applied in both _ICON_ROTATION (HUD) and _cursor_for_tool (overlay cursor) so HUD icons and active cursors stay visually aligned. Hotspot for pen/highlighter stays at (2, 2) since the tip still lands in the top-left corner after the 90° rotation.
Two related fixes: 1. qtawesome's rotated= parameter did not consistently apply to icons rendered as pixmaps (used for cursors), so the pen and highlighter cursors kept the default bottom-right tip orientation even though the HUD icons themselves rendered correctly at rotated=90. Rotation now applies via QTransform.rotate(90) on the resulting pixmap, which is Qt-native and reliable across icon -> pixmap conversions. 2. Icons now render with a 1px black outline (8-direction dilation composited via QPainter) so pen/highlighter/eraser cursors and HUD buttons remain readable on light-coloured slides. Same compositing pattern used in both annotation_hud.py and annotation_layer.py to keep visual consistency between the toolbar and the active cursor. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Points defaultInterpreterPath to the local venv so Pylance resolves imports like pypdf, fitz, PySide6 without needing manual interpreter selection on every workspace open. Also whitelists workspaceFolder in analysis.extraPaths so 'from app import ...' resolves. Relaxes .gitignore to keep .vscode/settings.json and extensions.json tracked while ignoring the rest of .vscode/. Includes an extensions.json recommending the Python + Pylance + debugpy trio. Fixes user-reported 'Import "pypdf" could not be resolved' errors after venv recreation.
Deploying pdfapps with
|
| Latest commit: |
e1df565
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f9d85f22.pdfapps.pages.dev |
| Branch Preview URL: | https://fix-presentation-hud-cursor.pdfapps.pages.dev |
The black outline stroke added in the previous commit was necessary for cursor icons - those float over arbitrary slide content and need extra visibility. But it was also being applied to the HUD toolbar icons, which sit on the fixed dark toolbar background and don't need it. The result was cluttered-looking toolbar icons. annotation_hud.py now renders icons cleanly (just rotation, no outline). annotation_layer.py keeps the outline logic for cursor pixmaps. Tests updated: former test_hud_icons_have_black_outline replaced with test_hud_icons_have_no_outline (regression against re-adding outline to HUD); test_cursor_icons_have_black_outline retained (regression against losing outline on cursors).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three UX fixes for the presentation-mode annotation HUD:
Fixes
_cursor_for_tool()helper (new, inannotation_layer.py)ArrowCursor+90degviaQTransform.rotate(), with a 1px black outline composited via 8-direction QPainter dilation, hotspot at(4, 4)so the tip lands at the click positionBlankCursor(the red dot is painted manually inpaintEvent)_tool_qta_icon()helper (new, inannotation_hud.py)QTransformrotation applied to HUD buttons, so the toolbar row and the active cursor stay visually aligned.Why
QTransformand notqta.icon(..., rotated=90)The initial fix used
qtawesome'srotatedoption. Debug rendering showed it works offscreen, but user-side runtime reports were inconsistent — likely a corner case where the option doesn't propagate through the pixmap pipeline. Switching to Qt-nativeQTransform.rotate(90)on the resulting pixmap removes the dependency on qtawesome's kwargs and produces a deterministic result across all Qt versions.Why the outline
Pen and highlighter tips are single-colour glyphs, and in dark-mode presentation they're rendered in white. On white or light-yellow slides the shape would blur into the background. An 8-direction offset dilation (drawing the same glyph in black at (+/-1, 0), (0, +/-1), and diagonals) produces a clean 1px outline without needing SVG editing or a bespoke stroke path.
Iteration record
The rotation value went through pixel-level verification: 12 candidate rotations were rendered offscreen at 48x48 and their darkest-pixel centroid was located.
+90degwas the only value that produced a top-left tip matching the pointer, ruling out earlier guesses of-90degand180deg.Tests
tests/test_annotation_hud.py— 10 source-level regression tests:set_toolcallssetCursorValidation
tests/test_annotation_hud.py-> 10 passedAPP_VERSIONbumpManual QA before merge
Launch presentation mode (F5), open a light-coloured slide, verify: