Resize arrow direction improvement

[pascalfleury]

When resizing a window (e.g. -r then using the arrow keys) the direction in which the I have to press the keys seems random. Some windows I have to press 'down' to get the window to increase by moving its only movable border up.

I suggest to have a better selection of the direction in which things move, based on 'movable border'. A window that is tiled at the border of the screen has that border unmovable. the other borders, if they touch another window, are therefore movable.

When resizing, i3 could let the user use the arrow keys to move only the movable border of a window. If a window is in a corner, then moving up/down will move the horizontal edge of the window that is not on the screen edge in the direction of the arrows.

I think it would make the whole operation more intuitive, as I did not find any hint helping me find what will happen when I press keys, and end up trying all of them to see (a bit like plugging a micro-USB...).

[Airblader]

If you look at what commands are executed in the resize mode, you might understand what's going on. Reading the docs on that command would also help.

[pascalfleury]

I know. I still claim it is not the most intuitive when using arrow keys, but there is currently no way to configure it so that the movable border moves in the direction of the arrow (which would need some dynamic window state information).

$ i3 --version
i3 version 4.11 (2015-09-30, branch "4.11") © 2009 Michael Stapelberg and contributors

My config is within resize is:
bindsym Left resize shrink width 10 px or 5 ppt
bindsym Down resize grow height 10 px or 5 ppt
bindsym Up resize shrink height 10 px or 5 ppt
bindsym Right resize grow width 10 px or 5 ppt

[stapelberg]

I don’t see a pressing need (i.e. there are no frequent user complaints about this) to do anything about the resize commands.

Personally, I typically resize using the modifier + mouse dragging, as that’s by far the easiest way for me.

I think most users who frequently resize get used to the current behavior — this isn’t to say the current behavior is the optimal behavior, but there is a cost to changing it, too, so any suggestion must be significantly better.

If you feel strongly, I think the best way to move forward is to send a pull request and discuss the various cases based on the pull request.

[Airblader]

but there is a cost to changing it, too

In particular either a breaking change for users as well as scripts or maintaining two different resize mechanisms.

[Airblader]

A month has passed, so I think there's no strong enough opinion. The way I take it, neither @stapelberg nor I think this is significantly better than the current way, therefore not justifying the breaking behavior change.

The offer stands, anyone wanting to provide a PR to push this topic can do so.