Minor fixes to built-in themes

[maruuk]

No background for clipboard suggestions in dynamic color theme. It's present in other themes.

In the "forest" theme, some toolbar keys are highlighted. Looks like a bug.

The key highlighting in the popup only appears in the dynamic colors theme. I think it would be nice if it appeared in other themes as well.

[Helium314]

In the "forest" theme, some toolbar keys are highlighted. Looks like a bug.

The highlighting is also visible in your screenshot at the bottom, it's just not as strong.

If anyone wants to tune the built-in themes, they are here: https://github.com/HeliBorg/HeliBoard/blob/main/app/src/main/java/helium314/keyboard/keyboard/KeyboardTheme.kt#L217-L337

The dynamic theme is a bit more complicated: https://github.com/HeliBorg/HeliBoard/blob/main/app/src/main/java/helium314/keyboard/latin/common/Colors.kt#L86

[MiMoHo]

Took a closer look at the clipboard-suggestion part — it's a one-line omission in the dynamic theme:

DefaultColors.setBackground handles CLIPBOARD_SUGGESTION_BACKGROUND explicitly (Colors.kt:530, together with STRIP_BACKGROUND etc.), which tints the white pill drawable with doubleAdjustedBackground so it stands out from the strip. DynamicColors.setBackground (Colors.kt:341) is missing that case, so the pill falls into the else branch and gets tinted with plain background — i.e. exactly the strip color, which is why it looks like it has no background. Notably DynamicColors.get(CLIPBOARD_SUGGESTION_BACKGROUND) already returns the correct doubleAdjustedBackground (Colors.kt:291); it's just never used by the dispatch. The commit that introduced clipboard suggestions (bdab98c, #647) added the ColorType to get() of both classes but to setBackground only in DefaultColors, so this looks like a simple oversight.

Fix is adding CLIPBOARD_SUGGESTION_BACKGROUND to the list in DynamicColors.setBackground (Colors.kt:341) — that reproduces the DefaultColors path 1:1. Not visually verified yet on an Android 12+ device; happy to submit it as a PR after doing that.

On the forest highlighting: the toolbar tint list uses suggestionText for activated keys and brighten(brighten(suggestionText)) for non-activated ones (Colors.kt:403-407), and brighten adds an absolute luminance step (+0.06, ColorUtil.kt:51-55). Forest's suggestionText is rgb(0,50,0) (KeyboardTheme.kt:275, L≈0.10), so two steps roughly double its brightness — while for themes with near-white text the same two steps are barely visible. That's why the same mechanism looks so much stronger on forest, matching what you said. A perceptually consistent alternative would be alpha-based dimming for the non-activated state instead of absolute luminance steps, but that changes all themes, so it's your call.

[maruuk]

It looks like the clipboard suggestion issue was fixed in this PR #2659

A perceptually consistent alternative would be alpha-based dimming for the non-activated state instead of absolute luminance steps, but that changes all themes, so it's your call.

This highlight is visible only in the Light, Dynamic, and Forest themes. And it’s inverted. It disappears when those keys are activated, which is strange. Is it possible to simply remove this highlight to maintain consistency with the other themes?

Could you also take a look at 3? It would be great if you could implement key highlighting in the popup.

[MiMoHo]

@maruuk I took a crack at the popup key highlighting (your point 3): the long-press popup's selected key now uses the theme accent so it's clearly visible, dimmed a bit for the dynamic theme so it isn't glaring — #2689. The clipboard-suggestion part is already fixed by #2659.

That leaves the inverted toolbar highlight (Light/Dynamic/Forest). If you'd still like that gone too I can add it; otherwise, once this is merged I think #2440 can be closed.

[maruuk]

Thank you!

That leaves the inverted toolbar highlight (Light/Dynamic/Forest). If you'd still like that gone too I can add it

It would be nice if you could fix that too.