Skip to content

Support additional rain configuration#2

Open
Thedoczek wants to merge 1 commit into
Ian-bug:masterfrom
Thedoczek:master
Open

Support additional rain configuration#2
Thedoczek wants to merge 1 commit into
Ian-bug:masterfrom
Thedoczek:master

Conversation

@Thedoczek

@Thedoczek Thedoczek commented Jun 14, 2026

Copy link
Copy Markdown

As a response to #1

The PR doesn't contain edits to the README.md and any other documentation that might require it.

Summary by CodeRabbit

Release Notes

  • New Features
    • Added customizable fade effect settings for falling keys: adjust fade start position, fade length, and choose whether the fade is triggered by the key head or tail.

@coderabbitai

coderabbitai Bot commented Jun 14, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

Fade configuration is relocated from static DisplayConstants constants (FADE_START_Y, FADE_RANGE) into KeyViewerSettings as three new user-configurable fields: fade_position_y, fade_length_y, and fade_trigger. Validation, persistence, overlay rendering, and UI controls are all updated accordingly.

Changes

Configurable Fade Settings

Layer / File(s) Summary
Fade fields and validation in KeyViewerSettings
core/configuration.py
FADE_START_Y and FADE_RANGE are removed from DisplayConstants; fade_position_y, fade_length_y, and fade_trigger are added to KeyViewerSettings with defaults. validate() clamps values against max screen height from QApplication.screens() and enforces "head"/"tail" for fade_trigger.
Persistence round-trip for fade fields
core/settings_manager.py
load() reads the three new keyviewer fade fields with fallback defaults (800, 200, "head"); save() writes them back, ensuring round-trip fidelity.
Overlay fade rendering using new config fields
core/overlay.py
_draw_active_bars reads fade_position_y, fade_length_y, and fade_trigger from key_viewer config; alpha is now derived from dist_head or dist_tail depending on fade_trigger.
Settings UI controls for fade fields
core/ui/components.py, core/gui.py
KeyViewerSettingsGroup gains spin boxes for fade_position_y/fade_length_y and a head/tail combo box for fade_trigger, with QApplication used to cap spin box ranges to max screen height; on_change() and update_from_config() are extended for the new widgets. SettingsWindow resized to 410x722.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐇 Hop, hop, the constants roam,
From DisplayConstants, now they've flown!
fade_trigger says "head" or "tail,"
Spin boxes set, no config stale.
The raining keys now fade just right —
A configurable, glowing night! ✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Support additional rain configuration' directly describes the main change: adding new fade configuration parameters (fade_position_y, fade_length_y, fade_trigger) to KeyViewerSettings and integrating them across the codebase.
Docstring Coverage ✅ Passed Docstring coverage is 87.50% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
core/ui/components.py (1)

341-351: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Block fade-trigger combo signals during config sync to avoid re-entrant saves.

Line 364 updates combo_kv_fade_trig, but it isn’t included in signals_blocked(...) (Lines 341-351). That can emit currentTextChanged, call on_change(), and trigger an unnecessary nested save() cycle.

Suggested fix
         with signals_blocked(
             self.chk_kv_enabled,
             self.spin_kv_height,
             self.combo_kv_pos,
             self.spin_kv_off_x,
             self.spin_kv_off_y,
             self.spin_kv_opacity,
             self.chk_kv_counts,
             self.spin_kv_fade_pos,
-            self.spin_kv_fade_len
+            self.spin_kv_fade_len,
+            self.combo_kv_fade_trig
         ):

Also applies to: 364-364

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@core/ui/components.py` around lines 341 - 351, The signals_blocked() context
manager (lines 341-351) does not include self.combo_kv_fade_trig in its list of
widgets, but this widget is updated at line 364. When the widget is updated
outside the signal blocking context, it emits currentTextChanged, which calls
on_change() and triggers an unnecessary nested save() cycle. Add
self.combo_kv_fade_trig to the list of widgets passed to the signals_blocked()
call to prevent signal emission during configuration synchronization.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@core/configuration.py`:
- Around line 154-157: The clamping operation for fade_length_y uses max(0, ...)
which allows the value to drop below the minimum bound of 10 that was validated
on line 154, potentially causing division by zero in _draw_active_bars(). Fix
this by changing the max(0, ...) call to max(10, ...) to enforce the consistent
minimum bound of 10 that matches the validation check.

---

Outside diff comments:
In `@core/ui/components.py`:
- Around line 341-351: The signals_blocked() context manager (lines 341-351)
does not include self.combo_kv_fade_trig in its list of widgets, but this widget
is updated at line 364. When the widget is updated outside the signal blocking
context, it emits currentTextChanged, which calls on_change() and triggers an
unnecessary nested save() cycle. Add self.combo_kv_fade_trig to the list of
widgets passed to the signals_blocked() call to prevent signal emission during
configuration synchronization.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 7863bbf6-690c-4393-9cbd-598f36b20afc

📥 Commits

Reviewing files that changed from the base of the PR and between 94de54b and f0433b1.

📒 Files selected for processing (5)
  • core/configuration.py
  • core/gui.py
  • core/overlay.py
  • core/settings_manager.py
  • core/ui/components.py

Comment thread core/configuration.py
Comment on lines +154 to +157
if not (10 <= self.fade_length_y <= max_screen_y):
logger.warning(f"Fade length {self.fade_length_y} out of range [10, {max_screen_y}], clamping")
self.fade_length_y = max(0, min(max_screen_y, self.fade_length_y))
valid = False

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Clamp for fade_length_y violates its own minimum bound and can crash rendering.

Line 154 enforces a minimum of 10, but Line 156 clamps with max(0, ...), which allows 0. That can propagate to _draw_active_bars() and trigger division by zero at dist_into_fade / fade_length_y.

Suggested fix
-        if not (10 <= self.fade_length_y <= max_screen_y):
+        if not (10 <= self.fade_length_y <= max_screen_y):
             logger.warning(f"Fade length {self.fade_length_y} out of range [10, {max_screen_y}], clamping")
-            self.fade_length_y = max(0, min(max_screen_y, self.fade_length_y))
+            self.fade_length_y = max(10, min(max_screen_y, self.fade_length_y))
             valid = False
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
if not (10 <= self.fade_length_y <= max_screen_y):
logger.warning(f"Fade length {self.fade_length_y} out of range [10, {max_screen_y}], clamping")
self.fade_length_y = max(0, min(max_screen_y, self.fade_length_y))
valid = False
if not (10 <= self.fade_length_y <= max_screen_y):
logger.warning(f"Fade length {self.fade_length_y} out of range [10, {max_screen_y}], clamping")
self.fade_length_y = max(10, min(max_screen_y, self.fade_length_y))
valid = False
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@core/configuration.py` around lines 154 - 157, The clamping operation for
fade_length_y uses max(0, ...) which allows the value to drop below the minimum
bound of 10 that was validated on line 154, potentially causing division by zero
in _draw_active_bars(). Fix this by changing the max(0, ...) call to max(10,
...) to enforce the consistent minimum bound of 10 that matches the validation
check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant