| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #1120
When the parent of a view is C_WORKSPACE and the movement direction
is either MOVE_PREV or MOVE_NEXT, the code would attempt to move the
views to the next output, but swayc_adjacent_output can't accept
non-directional movement commands and causes undefined behaviour and
a segfault.
If the code is simply skipped, we end up in an infinite loop.
Instead, we can allow containers whose parent is a C_WORKSPACE take the
path that handles MOVE_PREV and MOVE_NEXT, which behaves as you would
expect.
I'm not certain that this fix is entirely correct as the desired behaviour
of move_container is not very well defined, but it seems to work.
|
| |
|
|
|
|
|
|
|
| |
This commit lets the 'move' command apply to floating containers as well
as tiled ones. The command may be appended with a number of pixels and
then optionally the string `px` (like '10 px') in order to move the
container more or fewer than the standard ten pixels.
|
| |
|
|
|
|
|
|
| |
Previous implementation would not preserve dimension of groups
along the major axis. This should avoid weird behavior when
using container motion commands.
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Achieved by introducing auto_group_bounds function that produces
the start/end indexes of a group inside an auto layot container.
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| | |
This is more consistent with other Sway semantics.
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
| |
If workspace layout is set to tabbed or stacked, its C_VIEW children
should get wrapped in a container. Alongside that, move_container was
modified to retain previous functionality.
|
|
|
|
|
| |
Add swayc_change_layout function, which changes either layout or
workspace_layout, depending on the container type.
|
| |
|
| |
|
|
|
|
|
|
| |
Add swayc_change_layout function, which changes either layout or
workspace_layout, depending on the container type. Workspace being
always L_HORIZ makes this much more i3-compatible.
|
|
|
|
|
| |
If we want to add a sibling of different type than current
container it failed. Because we add it to the wrong list
|
|
|
|
| |
It will also wrap if needed.
|
| |
|
|
|
|
|
| |
Introduces container wrapping - if there is no other viable move, the
selection wraps on the first container where such action is possible.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch makes it possible to move views between outputs using the
`move left|right|up|down` commands.
It behaves similar to i3 with one important difference. The focus will
always follow the view being moved, unlike i3 where the focus doesn't
always follow the view to a new output (I assume that's a bug in i3).
|
|
|
|
|
|
|
|
|
| |
`vertical` and `horizontal` should be swapped.
If border_left and border_right were set to 0, the vertical borders
instead of the horizontal borders would be hidden.
i3 handles this command equally.
|
| |
|
|
|
|
| |
This should fix #839
|
|
|
|
|
|
| |
Replace `update_view_border()` with `update_container_border()`. The latter
should handle both the case where the container is a view or if the container
has children.
|
| |
|
|
|
|
|
|
|
|
|
| |
When titlebar is hidden, top border of the topmost view inside
tabbed/stacked container will not be drawn. This is changed in layout.c
On the other hand, top border should be drawn sometimes, for example
when titlebar is hidden on a view that is not the topmost inside
tabbed/stacked container. This is changed in border.c
|
| |
|
| |
|
|\
| |
| | |
bugfix: invisible windows on empty workspace with tabbed/stacked layout
|
| |
| |
| |
| | |
with 0x0 geometry
|
|/
|
|
|
| |
The `focus child` command focuses the child container within the selected
container.
|
| |
|
| |
|