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

ipc has no good way to reorganize containers #6903

Open
Hippo0o opened this issue Mar 20, 2022 · 3 comments
Open

ipc has no good way to reorganize containers #6903

Hippo0o opened this issue Mar 20, 2022 · 3 comments
Labels
enhancement New feature or incremental improvement i3-compat Sway doesn't match i3's behavior

Comments

@Hippo0o
Copy link

Hippo0o commented Mar 20, 2022

my main goal is to move a container from anywhere in the workspace back to workspace level but:

  • move container to workspace does nothing when same workspace
  • [con_id=x] mark --add a does not work on workspace and so move container to mark x can't be used like it worked in i3
  • containers can't be moved to ancestors
  • using directional move makes it way too complex

my use case: auto layout master stack

problem when: layout T[h|v] and window in h gets closed or moved so T[v] needs become T[h|v]

in i3:

  • i moved last focused in T[v] to workspace container which made it T[v|h] if v only had 1 container, it ends here with T[h]
  • then move v to workspace container which made it T[h|v]

in sway:

  • workspace is not a container, so it can't be marked nor can a container be moved to workspace level
  • if i go with T[h[h|v]] to workaround this, i can't move v to T[h] because moving to ancestor is not possible

proposal (either):

  1. make move to workspace also move the container back to workspace level
  2. make workspace behave like a container again which includes moving to it from descendants
  3. always make a default layout container and allow moving to ancestor
  4. allow moving to ancestor
@Hippo0o Hippo0o added the enhancement New feature or incremental improvement label Mar 20, 2022
@rpigott rpigott added the i3-compat Sway doesn't match i3's behavior label Apr 25, 2022
@rpigott
Copy link
Member

rpigott commented Apr 25, 2022

Can you clarify how sway's behavior differs from i3 here? It's easiest if you have a simple reproducer example, like

  1. initial layout
  2. some swaymsg/i3-msg commands
  3. result layout in i3 and sway that differs

@Hippo0o
Copy link
Author

Hippo0o commented Apr 28, 2022

image_2022-04-28_10-24-15
with a layout like this: its either W[H|V[H|H]] or W[H[H|V[H|H]]]

W: workspace
H: horizontal container
V: vertical container
H[H|H]: horizontal container with 2 horizontal child containers

scenario 1: W[H|V[H|H]]

in i3:

i3-msg [con_id="id of workspace container"] mark target
i3-msg [con_id="window with focus in screenshot"] move to mark target

W[H|V[H|H]] --> W[H|V[H]|H]

in sway:

workspace can't be marked as it explicitly is not a container.

scenario 2: W[H[H|V[H|H]]]

in i3:

i3-msg [con_id="id of W[H], basically first horizontal container in workspace tree"] mark target
i3-msg [con_id="window with focus in screenshot"] move to mark target

W[H[H|V[H|H]]] --> W[H[H|V[H]|H]]

in sway:

swaymsg [con_id="id of W[H], basically first horizontal container in workspace tree"] mark target
swaymsg [con_id="window with focus in screenshot"] move to mark target

does mark but not move bcs W[H[H|V[H|H]]] is ancestor of W[H[H|V[H|H]]]

|| container_has_ancestor(destination, container)) {

@ccdunder
Copy link

Related: #6818 and #6835

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 i3-compat Sway doesn't match i3's behavior
Development

No branches or pull requests

3 participants