Bug 503686 - Feedback and Bug Report: UX Issues and Inconsistencies in KDE's Color Scheme Editor
Summary: Feedback and Bug Report: UX Issues and Inconsistencies in KDE's Color Scheme ...
Status: RESOLVED NOT A BUG
Alias: None
Product: systemsettings
Classification: Applications
Component: general (other bugs)
Version First Reported In: 6.3.4
Platform: Fedora RPMs Linux
: NOR major
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: accessibility, usability
Depends on:
Blocks:
 
Reported: 2025-05-02 20:49 UTC by KDE User
Modified: 2025-05-06 16:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description KDE User 2025-05-02 20:49:39 UTC
SUMMARY

Hi KDE team,

First of all, thank you for the incredible work you continue to do. KDE is one of the most powerful and flexible desktop environments out there, and features like the Edit Color Scheme tool really highlight that. I wanted to share some thoughts and observations from my recent experience using this feature—mainly around a few quirks and potential improvements that could help polish the user experience even further. This bug report addresses several UX issues and bugs in KDE’s foreground color editor, found under Settings > Colors > Edit Color Scheme (the dialog that opens after clicking the pencil icon on each color theme).

One issue I noticed is that when I use the "Save As" option to create a new color scheme, the changes don’t immediately reflect in the UI. I often need to switch pages or navigate away and back again before the new theme appears correctly. Similarly, after making changes through the Edit Color Scheme dialog and saving them, the Apply button remains disabled—even though a modification was clearly made. From a UX perspective, enabling that button post-save would offer a clear signal to the user that changes are ready to be applied.

There’s also some confusion when trying to apply the saved theme. After saving edits, the theme doesn’t immediately take effect until I switch to another theme and then back again. It creates a feeling that the system didn’t register the changes, which might be discouraging for users trying to explore customization.

Another point I’d love to highlight: the Edit Color Scheme button itself could be emphasized a bit more in the UI. It’s a powerful customization feature, yet it's easy to overlook—especially for users who assume they can only change accent colors. Foreground color editing is a big deal, and many users (myself included) didn’t even realize it was possible for the longest time.

This becomes even more important with KDE 6.4, which introduces a darker foreground by default. While many users may welcome the new aesthetic, others might prefer something lighter or different for accessibility or personal taste. Giving more visibility to the color editing options will help people discover and appreciate just how customizable KDE really is.

A few more observations:

- When I copy and darken the Breeze theme, everything seems fine—until I focus on other application windows, at which point the theme partially reverts to default Breeze colors for unfocused windows. I confirmed that all relevant values were updated, so this may be a rendering or caching issue. Interestingly, when I start with a stock dark theme and customize it, this issue doesn’t occur. That suggests the bug might be linked specifically to saving or modifying derived themes based on Breeze. Or this also suggests that color editing options might be missing.

- Additionally, updating the tab buttons to use the modern, evenly distributed style that fills the available space would improve consistency with other parts of the system where this standard layout is already being used.

- Finally, I've noticed that some color changes don’t save correctly. It's possible this is related to built-in contrast enforcement, which is understandable. But given how much freedom KDE already provides with accent colors, it might make sense to offer users full control here—even if it means letting them choose combinations with poor contrast. Sometimes, creative expression trumps readability.

Overall, despite the hiccups, I’ve really enjoyed using this feature. It adds a lot of personality to the desktop, and I deeply appreciate that KDE gives users this level of control. These suggestions come from a place of admiration for the work already done—and excitement for what’s ahead. KDE 6.4 is a great update, and it would be even better if the bugs in the foreground color editor were fixed!

Apologies for using AI to help write this—I relied on it because my grammar isn’t the best, and the message would have been much less clear if I had written it entirely on my own.

Thanks again for all your hard work and dedication to making KDE amazing!

Warm regards,
A grateful KDE user and tinkerer

STEPS TO REPRODUCE
1. (Many, listed above)
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
This is a general bug report covering multiple UX issues and bugs, so it doesn’t fit neatly into the standard template—apologies for that.
Comment 1 Nate Graham 2025-05-06 16:21:04 UTC
Thanks, but I'm afraid this isn't a bug report, it's an essay. :)

Bug reports need to be short, actionable, and about one specific issue; additional issues need to be tracked with additional bug reports. Also, please don't use AI to write any text you expect anyone else to read, as it  invariably ends up unreadably stilted and verbose.

If you'd like to discuss the design of the window in general, check out https://community.kde.org/Get_Involved/design.