There's no point having both movement_direction and wlr_direction. This
replaces the former with the latter.
As movement_direction also contained MOVE_PARENT and MOVE_CHILD items,
these are now checked specifically in the focus command and handled in
separate functions, just like the other focus variants.
The previous pull request #2993 tried to fix this by moving the function which
used the layers after the initilization.
Since this initialization is done unconditionally only depending on the struct
definition, move the layer initialization to the beginning of the function.
Also move the signal initialization of the destroy event.
Fixes#2992
input_manager_set_focus is used to set the focus after mapping the view in
view_map. This needs to consider to warp the cursor as well, since for
WARP_CONTAINER, the cursor should warp to the newly created view.
i3 seems to make all window properties, with the exception of
transient_for, optional[1].
[1]: 315ff17563/src/ipc.c (L435-L450)
Signed-off-by: Franklin "Snaipe" Mathieu <snaipe@diacritic.io>
It turns out that i3 does not have a `class` key in the json description
of a view, but provides it through `window_properties.class`. Since
`window_properties` has been added by 8fc9328, we can remove `class`
altogether.
Signed-off-by: Franklin "Snaipe" Mathieu <snaipe@diacritic.io>
In i3, when a child of a tabbed or stacked container has no siblings,
its border settings are respected.
This patch achieves the same effect by rendering a lone tabbed/stacked
child as if it's a linear container. This makes the border settings be
respected.
Over in view_autoconfigure, we compensate for this by only adjusting
`y_offset` if there's multiple children.
The code being changed is responsible for updating the focus stack when
a container is destroyed in a different part of the tree to where the
real focus is. It's attempting to set focus_inactive to a sibling (or
parent if no siblings) of the container that is being destroyed, then
put our real focus back on the end of the focus stack.
The problem occurs when the container being destroyed is in a different
workspace. For example:
* Have a focused view on workspace 1
* Have workspace 2 not visible with a single view that is unmapping
* The first call to seat_set_raw_focus sets focus to workspace 2 because
it's the parent
* Prior to this patch, the second call to seat_set_raw_focus would set
focus to the view on workspace 1
* Later, when using output_get_active_workspace, this function would
return workspace 2 because it's the first workspace it finds in the
focus stack.
To fix this, workspace 1 must be placed on the focus stack between
workspace 2 and the focused view. That's what this patch does.
Lastly, it also uses seat_get_focus_inactive to choose the focus. This
fixes a crash when a view unmaps while a non-container is focused (eg.
swaylock), because focus is NULL.
Ryan Dwyer
Drew DeVault
madblobfish
emersion
Rostislav Pehlivanov
Franklin "Snaipe" Mathieu
Brian Ashworth
mwenzkowski
Rouven Czerwinski
Cameron Nemo
Konstantin Kharlamov
Franklin "Snaipe" Mathieu
Robinhuett
Ryan Dwyer
Cole Mickens