-
-
Notifications
You must be signed in to change notification settings - Fork 732
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
hyprland/workspaces: Persistent workspace disappear after being active #2945
Comments
Thanks for the detailed report. I might have time to look into this tomorrow. In the meantime, can you post the trace logs where you start the bar and do the exact things to reproduce this issue? |
Nevermind, I can reproduce the issue locally. Will investigate. |
Can you test that PR @aruhier ? |
Thanks! It works better, but now the bug is more specific. If a persistent workspace is active when you start Waybar, then get empty (and removed by Hyprland) the problem occurs for this workspace. Otherwise, workspaces that are empty when Waybar starts don't have the problem anymore. |
I found the problem and I think I fixed it, I added a comment in your PR. |
Do you set the workspace as persistent in Hyprland or only in Waybar? |
I personally set it to persistent in Hyprland. The code is written in such a way that you shouldn't use both methods. You should either specify persistent workspaces in your waybar config, or specify them in your Hyprland config. No mixing. |
I'm asking this because not setting it in Hyprland is when the PR didn't work, compared to what I proposed. Because the workspace exists in Hyprland, it'll be created by If you set the workspace as persistent in Hyprland, then the workspace is never removed, which hides the issue. |
Fixes Alexays#2945 Split the config and rule persistency in 2 attributes, one storing the persistency as set in Waybar's config, the other one storing the persistency as set in Hyprland. It fixes some conflicts between the persistency state of a workspace as set in Waybar's config and its dynamic state in Hyprland. It allows to remove a persistent workspace in Waybar if this workspace is removed from Hyprland and if the workspace is not set as persistent in Waybar's config.
Fixes Alexays#2945 Split the config and rule persistency in 2 attributes, one storing the persistency as set in Waybar's config, the other one storing the persistency as set in Hyprland. It fixes some conflicts between the persistency state of a workspace as set in Waybar's config and its dynamic state in Hyprland. It allows to remove a persistent workspace in Waybar if this workspace is removed from Hyprland and if the workspace is not set as persistent in Waybar's config.
I wrote #2967, that fixes this bug.
Tell me if I'm wrong, but it should also fix this. Waybar will prefer the persistency state set in the config compared to the one set in Hyprland, but the 2 methods should work well together. |
Fixes Alexays#2945 Split the config and rule persistency in 2 attributes, one storing the persistency as set in Waybar's config, the other one storing the persistency as set in Hyprland. It fixes some conflicts between the persistency state of a workspace as set in Waybar's config and its dynamic state in Hyprland. It allows to remove a persistent workspace in Waybar if this workspace is removed from Hyprland and if the workspace is not set as persistent in Waybar's config.
Hi,
With commit 11310b8, a workspace set as persistent is not shown anymore after being active and then destroyed by Hyprland.
Config:
How to reproduce:
i
, it works as intended:i
is destroyed in Hyprland, and not persistent anymore in Waybar (it is not listed anymore):Reverting commit 11310b8 fixes this behavior.
CC @zjeffer for the #2603.
Edit: I forgot to specify that I don't set my workspaces as persistent in Hyperland, only in Waybar.
The text was updated successfully, but these errors were encountered: