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

hyprland/workspaces: Persistent workspace disappear after being active #2945

Closed
aruhier opened this issue Feb 20, 2024 · 9 comments · Fixed by #2967
Closed

hyprland/workspaces: Persistent workspace disappear after being active #2945

aruhier opened this issue Feb 20, 2024 · 9 comments · Fixed by #2967
Labels

Comments

@aruhier
Copy link
Contributor

aruhier commented Feb 20, 2024

Hi,
With commit 11310b8, a workspace set as persistent is not shown anymore after being active and then destroyed by Hyprland.

Config:

    "hyprland/workspaces": {
        "all-outputs": true,
        "format": " {icon}",
        "persistent-workspaces": {
            "*": [1, 2, 3, 4, 5, 6, 7, 8]
        },
    },

How to reproduce:

  1. Start waybar with persistent workspaces. All persistent workspaces are shown correctly at start. Using my config above, it'll show this:
    20240220_22h51m34s_grim
  2. Switch to a an empty workspace in Hyprland, set as persistent in waybar. For example, switching to i, it works as intended:
    20240220_22h51m51s_grim
  3. Switch to another workspace in Hyprland. Workspace i is destroyed in Hyprland, and not persistent anymore in Waybar (it is not listed anymore):
    20240220_22h52m04s_grim

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.

@zjeffer
Copy link
Contributor

zjeffer commented Feb 20, 2024

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?

@zjeffer
Copy link
Contributor

zjeffer commented Feb 20, 2024

Nevermind, I can reproduce the issue locally. Will investigate.

@zjeffer
Copy link
Contributor

zjeffer commented Feb 20, 2024

Can you test that PR @aruhier ?

@aruhier
Copy link
Contributor Author

aruhier commented Feb 20, 2024

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.

@aruhier
Copy link
Contributor Author

aruhier commented Feb 20, 2024

I found the problem and I think I fixed it, I added a comment in your PR.

@aruhier
Copy link
Contributor Author

aruhier commented Feb 22, 2024

Do you set the workspace as persistent in Hyprland or only in Waybar?

@zjeffer
Copy link
Contributor

zjeffer commented Feb 22, 2024

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.

@aruhier
Copy link
Contributor Author

aruhier commented Feb 22, 2024

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 initializeWorkspaces(), but the persistency is not set in Waybar. Then because the workspace already exists in Waybar, the persistency state is not set with this PR.

If you set the workspace as persistent in Hyprland, then the workspace is never removed, which hides the issue.

aruhier added a commit to aruhier/Waybar that referenced this issue Feb 24, 2024
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.
aruhier added a commit to aruhier/Waybar that referenced this issue Feb 24, 2024
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.
@aruhier
Copy link
Contributor Author

aruhier commented Feb 24, 2024

I wrote #2967, that fixes this bug.

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.

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.

aruhier added a commit to aruhier/Waybar that referenced this issue Feb 25, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants