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.

Sign up for GitHub

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

Jump to bottom

Hyprland: Special workspace switching is wonky #2861

Open
BenCarmichael01 opened this issue Jan 23, 2024 · 4 comments · May be fixed by #2864
Open

Hyprland: Special workspace switching is wonky #2861

BenCarmichael01 opened this issue Jan 23, 2024 · 4 comments · May be fixed by #2864
Labels
bug Something isn't working

Comments

@BenCarmichael01
Copy link

I have hyprland/workspaces module loaded in waybar and i have noticed that if i open an empty special workspace and then close it again, the regular workspace with the same number is removed from waybar.

Steps to reproduce:
Have hyprland/workspaces loaded into waybar
On workspace 1, open workspace special:1 using a defined key bind.
Close that special workspace with no windows on it.
Notice that the waybar workspaces module is now missing workspace 1.

I have repro'd this issue after running socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock and got this output:

createworkspace>>special:1
activewindow>>,
activewindowv2>>,
activespecial>>special:1,HDMI-A-1
activespecial>>,HDMI-A-1
activewindow>>kitty,nix-shell -p socat
activewindowv2>>3a2f8c0
destroyworkspace>>special:1

To me (not a programmer), it looks like it's because the hyprland socket doesn't report that workspace 1 is focused again after the special is closed. Only reporting the focused window, in my case kitty.
I initially thought this was a hyprland issue but after the above steps, switching between regular workspaces never brings back the one that "disappeared" on waybar despite hyprland correctly reporting the workspace switch.

Hope this made sense, if you need any more info/testing I'm happy to help!
@zjeffer
Copy link
Contributor

zjeffer commented Jan 24, 2024

This is probably caused by this: #2540

@Syndelis

@Syndelis Syndelis linked a pull request Jan 24, 2024 that will close this issue
Draft
@Syndelis
Copy link
Contributor

Hey there! It's a combination of problems: originally, some Hyprland IPC messages would purposefully not include the special: prefix, which brought previous work on Waybar to strip the prefix at first. This did cause some code not to correctly account for worksace "specialness" when comparing names, including the linked PR.

I'm working on a solution in #2864. Although the first commit already addresses this problem, I'm thinking of implementing a wrapper type for the name attribute so that you can't compare just names (think of Rust enums). I'll see where that gets me.

For the time, could you please try that PR, @Jaques22 ?

@BenCarmichael01
Copy link
Author

Amazing thanks that PR fixes the issues i was having. Special workspaces now show up like i'd expect.
Only thing i have noticed is that if i am on workspace 1 and open special:1 then i have two "1"s highlighted in my bar which i guess is technically correct? Though it would be nice to have the option of "special workspace focus overrides regular workspace" if possible but not sure its in the scope of this issue.

@Syndelis
Copy link
Contributor

Amazing thanks that PR fixes the issues i was having. Special workspaces now show up like i'd expect.
Only thing i have noticed is that if i am on workspace 1 and open special:1 then i have two "1"s highlighted in my bar which i guess is technically correct? Though it would be nice to have the option of "special workspace focus overrides regular workspace" if possible but not sure its in the scope of this issue.

Oh that's not a problem caused specifically because your special and regular workspaces share the same name, that's just a thing in waybar. If I'm not mistaken either Hyprland doesn't notify when the special is toggled or we are not listening to the right event (can't remember). I'll check later to see which is it and, if the latter, I'll implement it

@Alexays Alexays added the bug Something isn't working label Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix/Hyprland/Workspaces: Special Workspaces naming problems Syndelis/Waybar
4 participants
@zjeffer @Alexays @Syndelis @BenCarmichael01