font color problem

[TAforever]

Today I compiled waybar-git and on most modules the color began to match the color of the background. Version 0.9.13 does not have this problem.

[TAforever]

Here is version 0.9.13

[danielrparks]

This happens with the default style as well:

[frkli1965]

Related to issue #1726?

[danielrparks]

Looks like it's related. I bisected it to b8322c4b4b023d8e6fbe8b6bf4100d6c60a06e42 which is from the same PR referenced in that issue (#1120 ). Note that for me, this is affecting even non-custom modules.

[tpeacock19]

label:disabled,
button:disabled {
  color: inherit;
  background-image: none;
}

It seems like any module that does not have an "on-click" value in the config shows up as a disabled button. The above fixed this issue for me. Alternatively, you can add "on-click": "true", and it should pick up existing button styles.

[frkli1965]

Thanks tpeacock19 ...

Appending "on-click"; "true" to the config file helped to resolve the 'memory' module's font color for me whereas altering the 'style.css' with the provided suggestions didn't.

Decided to drop the "custom-menu" module as it's no longer supported it seems.

Kind regards,

[LudovicoPiero]

label:disabled,
button:disabled {
  color: inherit;
  background-image: none;
}

It seems like any module that does not have an "on-click" value in the config shows up as a disabled button. The above fixed this issue for me. Alternatively, you can add "on-click": "true", and it should pick up existing button styles.

This fixed my issue :+1:

[Alexays]

@pinselimo Can we add something like in #1738 to handle this issue?

[bklaase]

label:disabled,
button:disabled {
  color: inherit;
  background-image: none;
}

It seems like any module that does not have an "on-click" value in the config shows up as a disabled button. The above fixed this issue for me. Alternatively, you can add "on-click": "true", and it should pick up existing button styles.

that improves it, but the colors are still muted. As if maybe opacity is lowered as well

[tpeacock19]

I've found a more robust solution that may work for you. You'll have to add all: unset as the first declaration in these two rules:

button {
  all: unset;
  ...[other css declarations]...
}
label {
  all: unset;
  ...[other css declarations]...
}

The all: unset rules seems to put everything back to default. It should cover all variations between themes.

[Alexays]

3cf027fc567c343f5523b7b08476a467d5248b37 Should fix the pb Can someone try?

[TAforever]

3cf027f Should fix the pb Can someone try?

The change happened, but still there is an error.

[hajosattila]

Same problem here. Waybar 0.9.13 vs 0.9.15

• Arch
• Sway WM

[danielrparks]

I'm still having the same problem with the default style as well.

[Alexays]

And with 92cc01f?

[ChrisLane]

And with 92cc01f?

Just installed git package at that point in history. Seems to be fixed.

[danielrparks]

I still have the same problem with 92cc01f .

[TAforever]

And with 92cc01f?

Returned to the previous state.

[Alexays]

And with latest one 3030850? Sorry for the mess..

[roland-5]

And with latest one 3030850? Sorry for the mess..

Still grey.

[roland-5]

So with last commit, battery icon changed and with it, it's color to white. :P

[danielrparks]

The latest commit didn't work for me either.

[TAforever]

For the sake of interest, I decided to launch river with waybar in BSPWM and there is no such problem there. Maybe this information will be useful to you.

[TAforever]

And so: by experience, I realized that the problem lies in the GTK theme. For some reason, the font color started to depend on the theme. I installed the Gruvbox-Material-Dark theme instead of Qogir-dark as I have in BSPWM and there is no problem with the font.

[tpeacock19]

And so: by experience, I realized that the problem lies in the GTK theme.

Yes, I'm not sure there can be a solution implemented by Waybar since I imagine the theme will be applied after its loaded. The all: unset should be in the default configuration and perhaps highlighted in the wiki as a fix for this issue.

[TAforever]

And so: by experience, I realized that the problem lies in the GTK theme.

Yes, I'm not sure there can be a solution implemented by Waybar since I imagine the theme will be applied after its loaded. The all: unset should be in the default configuration and perhaps highlighted in the wiki as a fix for this issue.

@Alexays this seems to be the solution to the problem.

[danielrparks]

Indeed, adding

* {
    all: unset;
}

to my configuration causes it to start working at 92cc01f40149292d315456f7e5bbdad6dc099caf.

Sorry about that! It didn't occur to me that my gtk theme would be applied after waybar's style changes.

[Alexays]

Closed as reverted