Skip to content

Extend swap command to support workspaces #7907

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

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

fabianscode
Copy link

@fabianscode fabianscode commented Jan 12, 2024

This extends the swap command to also support workspace swapping.
It solves an issue a friend and me had in sway, which is swapping the
contents of two workspaces efficiently.

The syntax goes as follows:
swap workspace with [number] <name>

It will swap the content of the specified workspace with the content of
the currently focused workspace. The currently focused workspace stays
focused. If the other workspace doesnt exist, it will be created,
otherwise if the other workspace is empty afterwards, it will potentially
be destroyed.

It was achieved by simpy swapping relevant fields of the workspaces
and updating a few variables of the affected containers.

fabianscode and others added 3 commits January 12, 2024 16:02
The added command allow the user to swap the contents of two workspaces.

Co-authored-by: Arne <[email protected]>
This will have the function stop the recusive calls as soon as
the first view is found - unlike before
@emersion emersion added enhancement New feature or incremental improvement window-management Configuring and arranging toplevels labels Jan 26, 2024
@bonsaiiV
Copy link

bonsaiiV commented Feb 5, 2024

Why add an entirely new command? The swap command already exists and intuitively it should work on the content of workspaces too.

To me it feels more like there is an oversight with swap, that needs to be fixed, as it is not working with workspaces.

@simonfogliato
Copy link

I have been looking for a nice way to swap all windows from one workspace (on monitor one), to a second workspace (on monitor two). The swayr project looks promising but I'd love to see more stuff like this in native sway.

https://sr.ht/~tsdh/swayr/#menu-switchers

At the moment I have been using (swaymsg -t get_outputs) the following...

bindsym $mod+m output "HDMI-A-1" toggle
bindsym $mod+Control+Shift+Right move workspace to output right
bindsym $mod+Control+Shift+Left move workspace to output left
bindsym $mod+Control+Shift+Down move workspace to output down
bindsym $mod+Control+Shift+Up move workspace to output up

@fabianscode
Copy link
Author

Why add an entirely new command? The swap command already exists and intuitively it should work on the content of workspaces too.

To me it feels more like there is an oversight with swap, that needs to be fixed, as it is not working with workspaces.

I guess that seems reasonable... any other opinions?

@cartok
Copy link

cartok commented Feb 22, 2024

I have a script on my Todo list as a workaround and think this is really a good feature, especially when working with more than one screen.

@fabianscode fabianscode changed the title Add the swap_workspace command Extend swap command to support workspaces Feb 26, 2024
@fabianscode
Copy link
Author

Why add an entirely new command? The swap command already exists and intuitively it should work on the content of workspaces too.

To me it feels more like there is an oversight with swap, that needs to be fixed, as it is not working with workspaces.

the latest commit implements exactly that. Any thoughts?

Copy link

@bonsaiiV bonsaiiV left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This swaps the workspaces entirely. I was thinking about just inserting a container and swapping that, in case a workspace is selected to swap.
That's some different functionality.

Overall this approach looks fine. And basic testing showed, that it works.
I like it and think it is a nice addition. Maintainers seem reluctant about adding new stuff though. (to keep i3 compat)

Issues commented should get fixed though.

@@ -344,14 +344,20 @@ set|plus|minus|toggle <amount>
"Sticks" a floating window to the current output so that it shows up on all
workspaces.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep the old documentation and document the new syntax just below. That would just be simpler.

The documentation of the new syntax is also very short :

  • what happens to container focus
  • how is the argument specified (e.g. workspace with the number)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think to add that command you also need to link a function to that command in commands.c,
forgetting this here might break stuff

if (!oth_ws) {
oth_ws = workspace_create(NULL, ws_name);

if (!oth_ws) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think here is free(ws_name) missing and potentially leaking memory


// second workspace is the one currently focused
struct sway_workspace *cur_ws = config->handler_context.workspace;
if (!cur_ws) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exiting here will potentially leave oth_ws created, if it wasn't before

@@ -1,7 +1,9 @@
#include <strings.h>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this ever used?


struct cmd_results *cmd_swap(int argc, char **argv) {
struct cmd_results *error = NULL;
if ((error = checkarg(argc, "swap", EXPECTED_AT_LEAST, 4))) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this does not allow to identify the workspace by name as that uses 3 args


static void handle_container_after_move(struct sway_container *container,
void *data) {
node_set_dirty(&container->node);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

redundant as containers will be set dirty in arrange_workspace

// this needs to be more specific (focus not just every container,
// but single windows
struct sway_container *container = ws->tiling->items[0];
struct sway_container *first_view = container_get_first_view(container);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why focus first view? Shouldn't workspace->focused_inactive_child be the preferred way?

@bonsaiiV
Copy link

bonsaiiV commented Mar 9, 2024

I just noticed i3/i3#3952. This is what i described in my review. Since the maintainers want sway to be compatible to i3, it might be necessary to implement the enhancement for i3 first ... .

@fabianscode
Copy link
Author

I just noticed i3/i3#3952. This is what i described in my review. Since the maintainers want sway to be compatible to i3, it might be necessary to implement the enhancement for i3 first ... .

the way I understood it, the intension is for sway to be a superset of i3, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or incremental improvement window-management Configuring and arranging toplevels
Development

Successfully merging this pull request may close these issues.

5 participants