Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No Text Highlight Upon Workspace Buttons #3041

Closed
TeusLollo opened this issue Mar 19, 2024 · 9 comments
Closed

No Text Highlight Upon Workspace Buttons #3041

TeusLollo opened this issue Mar 19, 2024 · 9 comments
Labels
bug Something isn't working

Comments

@TeusLollo
Copy link

TeusLollo commented Mar 19, 2024

It appears that when work underwent for #2998, there were some highlighting bugs, including this one #2998 (comment), which was promptly fixed at grimpy@7b3d155

However, I have discovered another bug that went unnoticed:

Workspace text highlighting for focused workspace in 0.9.24

z2

Workspace text highlighting for focused workspace in 0.10.0

z1

Relevant style.css code is as follows, and is confirmed to be working in 0.9.24, but not anymore in 0.10.0:

@define-color wkspbase		#b711ff;
@define-color wkspvisib		#56f665;
@define-color wkspurgen		#ff0d0a;

#workspaces {
    padding:    	0px 0px 0px 0px;
    min-width:  	0px;
    margin:     	0px 0px 0px 0px;
}

#workspaces button {
    padding:    	0px 10px 0px 10px;
    min-width:  	0px;
    margin:     	0px 0px 0px 0px;
    color:      	@wkspbase;
}

#workspaces button.visible {
    padding:    	0px 10px 0px 10px;
    min-width:  	0px;
    margin:     	0px 0px 0px 0px;
    color:      	@wkspvisib;
}

#workspaces button.focused {
    padding:    	0px 10px 0px 10px;
    min-width:  	0px;
    margin:     	0px 0px 0px 0px;
    border-top: 	3px solid @wkspbase;
    border-bottom: 	3px solid @wkspbase;
}

#workspaces button.urgent {
    padding:    	0px 10px 0px 10px;
    min-width:  	0px;
    margin:     	0px 0px 0px 0px;
    color:      	@wkspurgen;
}

Hence, on 0.10.0, text highlighting seems broken for focused and urgent workspace states upon workspace buttons, regardless of workspace button non-text highlighting state.

Workspace highlighting as described in #2998 (comment) indeed was fixed, but not text highlighting, presumably since not many users actually rely on text highlighting, thus the bug went unnoticed.

@github-actions github-actions bot added the bug Something isn't working label Mar 19, 2024
@TeusLollo TeusLollo changed the title No Text Highlight On Active Workspace No Text Highlight Upon Workspace Buttons Mar 19, 2024
@WhyNotHugo
Copy link
Contributor

I have a similar issue and suspect that they're the same cause (please let me know if a separate issue is best).

#workspaces button {
  padding: 0 5px;
  background-color: transparent;
  color: #ffffff;
  border-bottom: 3px solid transparent;
}

#workspaces button.visible {
  border-bottom: 3px solid #ffffff;
}

With waybar 0.10.0, visible workspaces don't have the last style applied to them; they look just like inactive workspaces.

@braun-steven
Copy link

Can confirm. Waybar v0.10.0 broke the solutions to highlight a visible workspace on a second (unfocused) monitor proposed in #1403. Downgrading to v0.9.24 resolved the issue.

@tokyovigilante
Copy link
Contributor

git bisect:

7b3d155608d030094f813b5c1908e0017c202547 is the first bad commit
commit 7b3d155608d030094f813b5c1908e0017c202547
Author: Jo De Boeck <[email protected]>
Date:   Tue Mar 12 00:09:47 2024 +0200

    Fix peristant workspaces for sway

    Fixes: #2998

    Signed-off-by: Jo De Boeck <[email protected]>

 src/modules/sway/workspaces.cpp | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

@jakubvalenta
Copy link

When I run env GTK_DEBUG=interative waybar with Waybar v0.10.0 on my machine, I can see that none of the workspace buttons have the CSS class visible or persistent:

screenshot_2024-03-20_13-51-59

There is however current_output, which seems to mark those workspaces that have a window open. At least on my single-monitor setup. So I changed my style to use the class current_output for the time being.

@braun-steven
Copy link

Can confirm. Waybar v0.10.0 broke the solutions to highlight a visible workspace on a second (unfocused) monitor proposed in #1403. Downgrading to v0.9.24 resolved the issue.

This is now fixed by 7cd2a6c

@WhyNotHugo
Copy link
Contributor

I can confirm that this is fixed for me on master.

@rnestler
Copy link
Contributor

Can also confirmed it is fixed on master. Will this be included in the next release?

@TeusLollo
Copy link
Author

Can also confirmed it is fixed on master. Will this be included in the next release?

I second this.
I would prefert not to close this issue before it's ensured to be included into the next release, just in case further regressions manifest into current master

If even after that release this bug manifests again, anyone else can just reopen this, since it's a feature that can be easily overlooked during testing, it seems.

@TeusLollo
Copy link
Author

It's confirmed for https://github.com/Alexays/Waybar/tree/0.10.2 to have solved this.

Anyone is free to reopen this should it crop up again.

Closing this for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants