You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
workspace <name> output <outputs...>
Specifies that workspace name should be shown on the specified outputs. Multiple outputs can be listed and the first available will be used. If the workspace gets
placed on an output further down the list and an output that is higher on the list becomes available, the workspace will be moved to the higher priority output.
This command does not affect existing workspaces. To move an existing workspace, use the move command in combination with the workspace criteria (non-empty workspaces
only) or workspace command (to switch to the workspace before moving).
For the longest time (I've been using sway since 2020), this would work like a charm: when no output was connected to my laptop, the 8 workspaces would open on my laptop and as soon as I would plug a new output, the 1:a 2:s 3:d and 4:f workspaces would automatically move to the new output as it is higher priority, if they were already created (as stated in the first paragraph, emphasis mine, and contradicted in the second paragraph). If the workspace was not created, it would get created in the right output when first opening them.
Since about a year and a half ago (unfortunately I don't have the exact version, it's a really vague estimate), when plugging new outputs, it doesn't move my existing workspaces (seems in line with the second paragraph and not the first), but rather create a new, "1" workspace. When opening a new workspace, only the 5:u, 6:i, 7:o and 8:p will switch my focus to the laptop and create the workspace there. For the first four workspaces, it will open them in the output that is currently focused, not caring for priority, and only if they are not created yet.
Restarting sway does not change the workspace layout.
So there are two issues (maybe correlated, maybe separate):
New workspaces are not moved automatically when a new higher-priority output becomes available, or the first paragraph is misleading, used to represent the truth but is now obsolete.
The creation of new workspaces should respect priority when the outputs are already plugged in, but it doesn't for external outputs, only for the main, laptop, one.
The text was updated successfully, but these errors were encountered:
sweenu
changed the title
Contradiction in man page and regression
Contradiction in man page and regression in multi-output workspace creation
Jan 4, 2025
Sway Version: 1.10
Debug Log:
https://gist.github.com/sweenu/bd9a17c78ed43b849f0ea2eac89f8137
Configuration File:
https://gist.github.com/sweenu/fd452fe3f81587b86221b52e86f1370d
As requested: default config with only the relevant section (at the top) and a few line commented out to prevent errors.
Description:
The documentation states:
For the longest time (I've been using sway since 2020), this would work like a charm: when no output was connected to my laptop, the 8 workspaces would open on my laptop and as soon as I would plug a new output, the 1:a 2:s 3:d and 4:f workspaces would automatically move to the new output as it is higher priority, if they were already created (as stated in the first paragraph, emphasis mine, and contradicted in the second paragraph). If the workspace was not created, it would get created in the right output when first opening them.
Since about a year and a half ago (unfortunately I don't have the exact version, it's a really vague estimate), when plugging new outputs, it doesn't move my existing workspaces (seems in line with the second paragraph and not the first), but rather create a new, "1" workspace. When opening a new workspace, only the 5:u, 6:i, 7:o and 8:p will switch my focus to the laptop and create the workspace there. For the first four workspaces, it will open them in the output that is currently focused, not caring for priority, and only if they are not created yet.
Restarting sway does not change the workspace layout.
So there are two issues (maybe correlated, maybe separate):
The text was updated successfully, but these errors were encountered: