RFC: Locking containers - Prevent moving windows outside a container

[JakeHedman]

I'm submitting a…

[ ] Bug
[x] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Impact

[x] This feature requires new configuration and/or commands

Overview

Add a locked attribute to containers which prevents nodes being moved in and out of them. A locked container can be thought of as a workspace which can be moved around like a window.

A locked container can be used to group together related windows and prevent them from getting mixed up with unrelated windows when moving things around the layout.

Some windows just belong to each other and wants to be handled like a single unit, so it's common for editors, browsers and terminals to implement their own tiling/tabbing window managers. Being able to lock containers would make it easier to use i3 itself for managing these groups of windows.

Example use cases

Browser devtools

Having a browser's devtools in a separate window lets you use i3 to manage that split instead of using your browser as a tiling window manager inside your tiling window manager. It does however create another split in the i3 tree which can get in the way when moving stuff around. Locking them to each other by putting them in a locked vertical split would alleviate that. Losing track of which devtools window belongs to which browser is a strange experience.

Group of terminals

Putting a couple long-running terminals in a container to group them together is convenient. Locking that container would make it easier to handle the splits inside, and prevent outside windows from being moved inside when moving those around.

Editor + output

Pairs of editors and terminals are common, some editors even have terminals built in. You can also just use i3 to have an editor and terminal in the same container. Locking that container would make it feel more like those editor integrated terminals which can't get lost and end up somewhere else in the layout.

Programs with multiple windows

Ever wanted to use i3 to manage gimp's windows? Me neither. But if I wanted to, I'd want to lock those together and easily move them around like a unit without constantly having to keep track of which node in my i3 tree is the "root gimp container".

Behavior

Moving with move <direction>

Nodes can not be moved in or out of a locked container using the move <direction> command. They instead act similarly to when moving nodes around a workspace on a single monitor setup.

• Nodes can still be moved in and out of locked containers using the mouse and tags
• Locked containers are basically treated as leaf nodes when moving other nodes, other nodes swap places with them instead of being moved into them
• Locked containers are not "frozen" - their ancestors can still move around inside normally
• If a node "tries to move outside" of locked container, it behaves the same way as in a workspace (changing the orientation of the root etc), or does nothing (instead of moving to the next workplace)

Mouse

Locked containers can be moved with the mouse as a single unit using a modifier key (shift?).

New commands

locked enable|disable|toggle

Locks/unlocks the focused container.

default_locked_border normal|none|pixel / default_locked_border normal|pixel <px>

Works like default_floating_border to visually indicate that a container is locked. Trying to move nodes and getting "stuck" might be confusing without a visual hint.

focus parent locked

Focus the closest locked parent. Makes it easier to find and move a locked container without having to figure out how many focus parent are needed.

Titlebar

If shown, the titlebar of containers currently indicates the layout (V/H/T/S). Maybe locked containers should have some extra tag to indicate that state.

Thoughts? :)

[i3bot]

Please note that new features which require additional configuration will usually not be considered. We are happy with the feature set of i3 and want to focus in fixing bugs instead. We do accept feature requests, however, and will evaluate whether the added benefit (clearly) outweighs the complexity it adds to i3.

Keep in mind that i3 provides a powerful way to interact with it through its IPC interface: https://i3wm.org/docs/ipc.html.

[orestisfl]

Thoughts? :)

Interesting idea, likely (too) big development cost due to how the code is structured

[JakeHedman]

Thoughts? :)

Interesting idea, likely (too) big development cost due to how the code is structured

I'm not very familiar with the i3 codebase so please bear with me

Just looking at the core functionality and not nice-to-haves (mouse, focus parent, titlebar , border), there are two parts:

• Marking containers as locked
• Preventing nodes from entering/exiting them with move <direction>

I'm guessing most of the complexity/development cost comes from the second part. Is that due to how move.c is structured? Reading the tree_move() function makes it look easy, but I'm probably missing something?

[orestisfl]

move.c is one place which also has a few edge cases like for example what happens if the only eligible target is a locked container?

Additionally, there are plenty of other places which handle moving containers to other containers. For example, move to target/mark which is also used by the tiling drag feature.

Other cases would be when new containers are created and the new window will need to be a child/sibling of the locked container or when swapping containers.

Also, for all these cases we would probably need to handle two cases each time: not creating/moving containers as children of locked ones and not creating splits to locked containers in order to move other containers as their siblings.

Which also poses the question of what a layout splith/v would do in that case and when is it permitted to create splits on locked containers if ever

All this is from the top of my head and it's not a very well organized thought, some cases might be handled by shared code but not all of them.