waybar: highlight workspaces with open windows on Sway
Currently, waybar on sway does not indicate which workspaces have open windows. See below for an example:
Inside the virtual machine, workspace 1 has an open window (it's from the same setup as #246). This patch adds an indicator for that as seen in the waybar instance outside the VM (where workspaces 1, 3, and 6 have open windows).
I feel like this is a non controversial change, but it might just be something that sway is doing wrong (I am using the sway/workspaces module).
Currently, waybar on sway does not indicate which workspaces have open windows.
I also prefer active workspace indicators over no indicators.
I feel like this is a non controversial change
However, what indicator to use is controversial. Your border-bottom style looks clean on your setup, but I would use a background color on my setup.
Nonetheless, we should simplify the process of adding such widely used indicators. What about adding a generic Stylix option that places the user's indicator styling at the appropriate place in the theme file? Instead of an option trying to integrate the color into the theme as ${stylix.BEFORE}@base01${stylix.AFTER}, we should provide a generic string option that users can construct as desired: ${stylix.INDICATOR}.
On second thought, adding the generic option would be no different from the rest of the user's Waybar configuration. Maybe we should close this PR?
Related: https://github.com/danth/stylix/pull/220
On second thought, adding the generic option would be no different from the rest of the user's Waybar configuration. Maybe we should close this PR?
Related: #220
I'll check if setting programs.waybar.style works, but I think it was not possible last time I tried it.
I'll check if setting
programs.waybar.styleworks, but I think it was not possible last time I tried it.
If it does not work, maybe the solution is similar to https://github.com/danth/stylix/pull/230.
Since waybar is often heavily customised, it's hard to provide a module which isn't opinionated. Right now the module assumes that the styles won't be changed much by the user, so whatever we add here should be compatible in that case.
I figured out how to do it on my config instead see this commit.