Because reading the user's preferred color scheme uses the background color of their theme, it does not allow the user to directly set if they want other applications to use light or dark themes. This is especially a major issue because chromium based browsers now only allow websites to detect the system theme through the xdg portal, so users can not use a light theme for desktop programs, but use a dark theme with websites for example. An override value of some sort would be especially useful. This is not a bug per-say, but would be a very good feature to have.
> users can not use a light theme for desktop programs, but use a dark theme with websites for example Can you expand a bit on this to help us understand why this is a problem and why it should be solved with a change in KDE code?
(In reply to Nate Graham from comment #1) > Can you expand a bit on this to help us understand why this is a problem and > why it should be solved with a change in KDE code? Sure, at least to me, the background color value in the color scheme selected by the user and the value reported to other programs seem like they should be two separate values. Because other programs determine what color scheme they use from the theme files instead of a separate setting, they are effectively determining what the user wants in one case from what they want in another. I think that an implementation similar to that of the gtk desktop portal is better for the user here, as it reads a separate value from gsettings that can be manually set by the user if needed. Because in both cases the resulting value for the users preferred color scheme is emitted from the desktop portal, the only equivalent solution would be to implement a similar "manual override" in the KDE desktop portal.
> reads a separate value from gsettings that can be manually set by the user if needed So in Plasma, we don't have an exact analogue of this. The closest equivalent is our color scheme system. Using that system, the user registers their preference by selecting a color scheme, and this needs to be translated into the "does the user want dark mode" preference in the portal. As you've observed, the way we translate it is examining the lightness or darkness of the user-chosen color scheme. Seen in that way, it is already user-configurable. What I don't understand is how this causes a problem. You wrote: > users can not use a light theme for desktop programs, but use a dark theme with websites for example That seems like an unusual use case. Why do you want to use a light app theme but force websites into their dark themes? And if you do want this, wouldn't it make more sense to accomplish it with a browser plugin rather than tricking all portal-using apps into thinking that the user prefers a dark theme when they actually don't?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!