Bug 438273

I can't reproduce this on git master.

Can reproduce. All non-header color schemes don't have their distinct title bar color anymore

Noah, could you take another look maybe?

I'm not sure if its related or not, but I think I can reproduce the behavior by turning on and off the new "accent color" feature (I commended on the feature MR here: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/305#note_295265 ).

The behavior I see is:

1. in the Colors KCM, select default accent from color scheme, choose "Breeze" color scheme, and apply -> Title bar becomes dark (if it wasn't that before).
2. Choose an accent color and apply -> Title bar becomes window background colored.
3. Select default accent from color scheme and apply -> Title bar becomes dark again.

Regarding the content of `~/.config/kdeglobals` - with the color scheme accent color, there are no `Colors:header` groups in the file. When I set the accent color (to the first color, in this example), I get this in the file:

```
[Colors:Header]
DecorationFocus=233,58,154
DecorationHover=233,58,154
ForegroundActive=233,58,154
ForegroundLink=233,58,154
```

and setting back to accent from color scheme, that section gets removed.

I think I found the root cause of the issue.

When we switch color schemes, we first delete all the config groups and build up a new set of config groups. The presence or absence of the "[Header]" color group determines whether the color scheme is marked as having header colors.

However, calling kconfig::deleteGroup() doesn't *actually* delete the group. It instead changes all of the values of its keys to "[$d]" which I gather means "I've been deleted!" But the group itself still exists. so kconfig::hasGroup() will always return true for it.

Never mind, that was a red herring.

Found the real bug.

People who are affected have at least one more kdeglobals file on their system besides ~/.config/keglobals, and this other kdeglobals file has a color scheme specified in it that includes a [Colors:Header] group. Those people can work around it by removing the [Colors:Header] and [Colors:Header][Inactive] groups from that file.

When this file exists, the code that deletes the [Colors:Header] group when switching to a non-header color scheme doesn't actually delete the group and all its entries, it sets the keys' values to [$d] which is supposed to override the other file. However something about this does not work with the way we read colors from the color scheme to actually apply them to the system. Probably we are failing to check for whether the [Colors:Header] group exists or not, and are instead unconditionally reading its entries, rather than either checking for the group's existence using hasGroup() or verifying the existence of its entries' values with hasKey().

Next challenge is to find the actual piece of code that reads kdeglobals and applies the color scheme there to apps. Something in there is broken but I can't find where the code lives...

Plot twist: it looks like another element of it--or maybe all of it--is where KWin opens kdeglobals to read the active color scheme in abstract_client.cpp. It asks for kdeglobals wich makes use of the cascade config system.

In my case, I have a kdeglobals file located at ~/.config/kdedefaults/kdeglobals which has color data in it for Breeze Light. ~/.config/kdedefaults takes precedence over ~/.config/, so when KWin says, "yo, give me kdeglobals" it gets the data from ~/.config/kdedefaults/kdeglobals first. And that config file has a color scheme with header colors in it, so if ~/.config/kdeglobals specifies a color scheme without header colors, they get inherited automatically from ~/.config/kdedefaults/kdeglobals, if they exist there.

Removing ~/.config/kdedefaults/kdeglobals fixes the bug for me, though I'm still trying to figure out where it comes from.

For anyone else affected, do you also have a file at ~/.config/kdedefaults/kdeglobals which includes color data for a color scheme with header colors in it?

There is no kdedefaults folder on my PC

But it seems like I'm not affected anymore, unless I use an accent color. If I use the accent color from the color scheme it seems to work fine again

(In reply to Nate Graham from comment #9)
> In my case, I have a kdeglobals file located at
> ~/.config/kdedefaults/kdeglobals which has color data in it for Breeze
> Light.

I don't have a ~/.config/kdedefaults in my system, but also - with the current Neon unstable builds - I can no longer reproduce the issue I reported on in comment #4.

Ben I see that this "kdedefaults" folder support was added in https://invent.kde.org/plasma/plasma-workspace/-/commit/0d0bca58cfd6dcdba6bb12f8f69d7b0f7d9e1b69.

Unfortunately this causes the problem here because ~/.config/kdedefaults/kdeglobals is preferred over ~/.config/kdeglobals anytime something opens kdeglobals, which can cause config data to be read from that file instead.

There might be a KConfig bug here in that 

key=value from ~/.config/kdedefaults/kdeglobals is read when key=[$d] from ~/.config/kdeglobals exists, but it should not be.

Ben, can you take a look?

I will take a look

Thank you!

(In reply to Zamundaaa from comment #11)
> But it seems like I'm not affected anymore, unless I use an accent color. If
> I use the accent color from the color scheme it seems to work fine again
That's Bug 443786 which I just fixed yesterday.

Ben and I investigated this and discovered that the issue was caused by an older version of the KCM defaults stuff which was thankfully never released to users. So the only people who were affected were devs who tested stuff and built plasma form source. Affected people can safely delete either ~/.config/kdedefaults/kdeglobals, or all of the color definitions inside that file.