Skip to content

fix: 修复自定义按键字色不生效#23

Merged
qiin2333 merged 1 commit intomasterfrom
fix/custom-key-text-color
May 6, 2026
Merged

fix: 修复自定义按键字色不生效#23
qiin2333 merged 1 commit intomasterfrom
fix/custom-key-text-color

Conversation

@qiin2333
Copy link
Copy Markdown
Contributor

@qiin2333 qiin2333 commented May 5, 2026

修复内容

  • 移除 CustomKeyBtn 中不可靠的 private get fgColor 访问器
  • 改为组件普通方法 getForegroundColor() 读取按下/切换态与 keyDef.textColor
  • 提取 resolveCustomKeyForegroundColor() 纯函数表达前景色选择规则
  • 提取 KeyFace() builder,统一普通按钮和六边形按钮的文字/图标渲染,减少重复代码

根因

配置保存链路能正确更新 keyDef.textColor,但渲染端在 ArkUI @Component struct 中通过 private get fgColor 再传给 UI modifier,实际表现为未稳定使用用户配置颜色,导致文字颜色回退为随系统深浅色变化。

验证

  • CustomKeyBtn.ets:无编辑器错误
  • hvigor assembleHap --mode module -p product=default --no-daemon:BUILD SUCCESSFUL

注意

工作树中已有 native 子目录无关变更未包含在本提交中。

Summary by CodeRabbit

发布说明

  • 重构

    • 优化了按钮组件的前景色逻辑,减少了代码重复。
  • 其他更新

    • 更新了依赖项版本。

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 5, 2026

📝 Walkthrough

Walkthrough

重构CustomKeyBtn的前景色逻辑,引入可复用的KeyFace()构建器来消除图标/文本渲染的重复代码;同时更新moonlight-common-c子项目的提交版本。

Changes

CustomKeyBtn前景色与渲染逻辑重构

Layer / File(s) Summary
辅助函数
entry/src/main/ets/components/CustomKeyBtn.ets
新增 resolveCustomKeyForegroundColor() 函数,根据 isActive 状态返回白色或指定颜色。
核心实现
entry/src/main/ets/components/CustomKeyBtn.ets
添加 getForegroundColor() 私有方法和 @Builder KeyFace() 构建器,统一处理图标/文本的前景色渲染逻辑。
集成应用
entry/src/main/ets/components/CustomKeyBtn.ets
更新 NormalBtn()HexagonBtn() 调用 this.KeyFace() 替代之前的内联条件渲染代码。

moonlight-common-c子项目版本更新

Layer / File(s) Summary
依赖版本
nativelib/src/main/cpp/moonlight-common-c
将子项目提交哈希从 7ed14144... 更新至 80f24085...

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

🚥 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 PR标题准确总结了主要变更:修复自定义按键文字颜色不生效的问题,与代码改动(重构ForegroundColor逻辑)直接相关。
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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
  • Commit unit tests in branch fix/custom-key-text-color

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.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

🧹 Nitpick comments (2)
entry/src/main/ets/components/CustomKeyBtn.ets (2)

93-108: ⚡ Quick win

getIconRes()KeyFace() 内被调用两次

第 95 行用于条件判断,第 96 行再次用于传给 Image(),导致 getButtonIconResource() 被重复调用。建议在 builder 内缓存到局部变量,既消除冗余调用,也避免两次调用结果不一致的理论风险。

♻️ 建议的重构
  `@Builder`
  KeyFace() {
-   if (this.getIconRes()) {
-     Image(this.getIconRes()!)
+   const iconRes = this.getIconRes();
+   if (iconRes) {
+     Image(iconRes)
        .width(this.keyDef.fontSize + 6)
        .height(this.keyDef.fontSize + 6)
        .fillColor(this.getForegroundColor())
        .objectFit(ImageFit.Contain)
    } else {
🤖 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 `@entry/src/main/ets/components/CustomKeyBtn.ets` around lines 93 - 108,
KeyFace() calls getIconRes() twice (once in the if condition and again when
constructing Image), which is redundant and could yield inconsistent results;
inside the KeyFace() builder, call getIconRes() once and store its result in a
local variable (e.g., iconRes) then use that variable in the if check and when
constructing Image(), leaving the Text branch unchanged (referencing KeyFace(),
getIconRes(), Image(), and Text() to locate the code).

35-37: 考虑添加 textColor 的空值处理

isActivefalse 时,函数直接返回 textColor。虽然当前所有代码路径都为其赋予了有效值(默认 '#E0FFFFFF'),但若某个地方意外传入空字符串,文字可能无法渲染。建议添加fallback:

function resolveCustomKeyForegroundColor(isActive: boolean, textColor: string): ResourceColor {
  return isActive ? OV_TEXT_WHITE : (textColor || OV_TEXT_WHITE);
}

或在类型层面用 ResourceColor 约束,确保所有 textColor 赋值都经过验证。

🤖 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 `@entry/src/main/ets/components/CustomKeyBtn.ets` around lines 35 - 37, The
resolveCustomKeyForegroundColor function currently returns textColor when
isActive is false which can propagate empty/null strings and break rendering;
update resolveCustomKeyForegroundColor to fallback to a safe color (e.g.,
OV_TEXT_WHITE) when textColor is falsy, or tighten the parameter type to
ResourceColor and validate callers to guarantee non-empty values, ensuring the
function (resolveCustomKeyForegroundColor) always returns a valid ResourceColor.
🤖 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.

Nitpick comments:
In `@entry/src/main/ets/components/CustomKeyBtn.ets`:
- Around line 93-108: KeyFace() calls getIconRes() twice (once in the if
condition and again when constructing Image), which is redundant and could yield
inconsistent results; inside the KeyFace() builder, call getIconRes() once and
store its result in a local variable (e.g., iconRes) then use that variable in
the if check and when constructing Image(), leaving the Text branch unchanged
(referencing KeyFace(), getIconRes(), Image(), and Text() to locate the code).
- Around line 35-37: The resolveCustomKeyForegroundColor function currently
returns textColor when isActive is false which can propagate empty/null strings
and break rendering; update resolveCustomKeyForegroundColor to fallback to a
safe color (e.g., OV_TEXT_WHITE) when textColor is falsy, or tighten the
parameter type to ResourceColor and validate callers to guarantee non-empty
values, ensuring the function (resolveCustomKeyForegroundColor) always returns a
valid ResourceColor.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a7a97779-dbd0-4231-a9ac-c71f8aaa3b58

📥 Commits

Reviewing files that changed from the base of the PR and between 2946e67 and 52f5f25.

📒 Files selected for processing (2)
  • entry/src/main/ets/components/CustomKeyBtn.ets
  • nativelib/src/main/cpp/moonlight-common-c

@qiin2333 qiin2333 merged commit d01f2bb into master May 6, 2026
2 checks passed
@qiin2333 qiin2333 deleted the fix/custom-key-text-color branch May 6, 2026 06:32
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