Compute foreground and background colours for setEnabled and setEditable in StyledText

[elsazac]

This PR adds consistent handling of both foreground and background colors for both setEnabled and setEditable functions

The foreground and background colors were computed only for setEnabled. This has to be done for setEditable as
well to achieve consistency. Both the functions setEditable and setEnabled now recomputes foreground and background colour (earlier only applied in setEnabled)
This commit also adds a distinct foreground and background colour combination. Earlier the editable and non-editable state showed no difference. This now improves visual differentiation in StyledText.

Test Snippet : Test.txt

The StyledText behaviour in non editable state is shown below :

Before :

After :

Fixes: #3132, Fixes: #230

[github-actions]

Test Results

  170 files  ±0    170 suites  ±0   26m 6s ⏱️ - 1m 54s
4 679 tests ±0  4 658 ✅ ±0   21 💤 ±0  0 ❌ ±0 
6 592 runs  ±0  6 437 ✅ ±0  155 💤 ±0  0 ❌ ±0 

Results for commit 3b33c43. ± Comparison against base commit 8e9c223.

♻️ This comment has been updated with latest results.

[BeckerWdf]

Does this still work fine when CSS styling is used in the IDE?

[sratz]

This is going to resolve, #230, correct?

[Copilot]

Pull request overview

This PR makes StyledText apply consistent foreground/background color recomputation for both setEnabled(...) and setEditable(...), and introduces a distinct visual style for the non-editable (but enabled) state.

Changes:

• Added a shared updateColors(enabled, editable) helper and invoked it from both setEnabled and setEditable.
• Introduced new system color choices for the enabled-but-non-editable state to improve visual differentiation.
• Guarded resetCache(...) / caret recomputation in setBackground/setForeground when content is not yet initialized.

[elsazac]

Both editable and enabled are true :

When editable is true and enabled is false :

When editable is false and enabled is true :

when editable and enabled are both false :

[elsazac]

This is going to resolve, #230, correct?

The enabled case wasn’t handled earlier, but it is now covered with most recent changes

[elsazac]

Does this still work fine when CSS styling is used in the IDE?

It should work as expected because there is no additional modifications that have been made differently in terms of implementation.

[elsazac]

Build looks good;
I would like to merge this by EOD if there are no outstanding concerns on this.

[github-actions]

Test Results (macos)

   53 files   -     1     53 suites   - 1   5m 2s ⏱️ - 2m 53s
4 531 tests ±    0  4 287 ✅ ±  0  244 💤 ± 0  0 ❌ ±0 
1 117 runs   - 1 013  1 086 ✅  - 982   31 💤  - 31  0 ❌ ±0 

Results for commit 92bcd29. ± Comparison against base commit cad012b.

[github-actions]

Test Results (linux)

   56 files   -    32     56 suites   - 32   4m 2s ⏱️ - 10m 27s
4 557 tests ±    0  4 337 ✅ ±    0  220 💤 ± 0  0 ❌ ±0 
1 161 runs   - 2 114  1 146 ✅  - 2 060   15 💤  - 54  0 ❌ ±0 

Results for commit 92bcd29. ± Comparison against base commit cad012b.

[elsazac]

I found an issue with testing in light theme, so updated changes accordingly. Attaching the screenshots for both light and dark theme here.

Both editable and enabled are true :

When editable is true and enabled is false :

When editable is false and enabled is true :

when editable and enabled are both false :

Snippet from #230 :

[SougandhS]

I found an issue with testing in light theme, so updated changes accordingly. Attaching the screenshots for both light and dark theme here.

New colours looks great !

[elsazac]

Merging this now;

[HeikoKlare]

This might have caused a regression: #3207

[BeckerWdf]

I think we should revert and work on a proper rework of this without a hurry.

[akurtakov]

This PR also makes cursor invisible on Gtk4.