The previous PR introduced an issue with tiling based actions
like SnapToEdge and SnapToRegion using outdated SSD margin
values when called via keybind while maximized. That resulted
in wrong offsets for the tiled windows.
This commit restores the functionality by forcing a re-calculation
of the SSD margin when changing the maximized state.
Thanks to @Flrian for reporting the issue via IRC.
...to reduce code duplication.
The function populates an array with views which meet any set of critera
from:
- current-workspace
- no-always-on-top
- no-skipWindowSwitcher (window-rule)
Make src/osd.c use this new interface. Note that always-on-top views are
still filtered out from the window-switcher and that desktop_cycle_view()
needs to be re-worked before always-on-top views can be opted in.
With the new keepBorder option enabled, the
ToggleDecorations action now has 3 states:
- the first time only disables the titlebar
- the second time disables the whole SSD
- the third time enables the whole SSD again
When the keepBorder action is disabled, the old 2-state
behavior is restored, e.g. the ToggleDecorations action
only toggles between on and off.
Fixes#813
Minimize the whole view-hierarchy from top to bottom regardless of which
one in the hierarchy requested the minimize. For example, if an 'About' or
'Open File' dialog is minimized, its toplevel is minimized also, and vice
versa.
For reference:
- This is consistent with in openbox, where child views (dialogs) can be
minimized, but when doing so the parent is also minimized.
- In mutter these types of dialogs cannot be minimized (via client-menu or
otherwise).
- In both openbox and mutter, when a toplevel window is minimized any open
children are also minimized.
This also improves the config robustness as invalid edge names will now
prevent the action to be created in the first place and the user gets
notified about the issue.
This makes explicit the subtle behavioral difference between
xwayland_view_unmap() and handle_unmap().
With this change, the XDG and XWayland versions of handle_map/unmap()
are now identical, which will make further refactoring possible.
Two types of window rules are supported, actions and properties. They are
defined as shown below.
<windowRules>
<!-- Action -->
<windowRule identifier="some-application">
<action name="Maximize"/>
</windowRule>
<!-- Property -->
<windowRule identifier="foo*" serverDecoration="yes|no"/>
</windowRules>
Rules are applied if windows match the criteria defined by the
'identifier' attribute which relates to app_id for native Wayland windows
and WM_CLASS for XWayland clients.
Matching against patterns with '*' (wildcard) and '?' (joker) is
supported.
Add 'serverDecoration' property.
view_minimize() does not need to call desktop_move_to_back() because the
stacking order is not changed and the windowSwitcher uses the scene-tree
nodes anyway.
Note: Movement of xwayland sub-views still relies on keeping server->views
in sync with z-order
- Make view_discover_output() static
- Call view_discover_output() only for floating views
- Deprecate view_output(); make it use view->output when possible
A fullscreen view currently has its output specified twice by:
- struct output *output
- struct wlr_output *fullscreen
view->fullscreen may also become a dangling pointer if the output is
disconnected, because view_on_output_destroy() clears view->output but
not view->fullscreen.
To eliminate the redundancy and the dangling pointer, let's change
view->fullscreen to a Boolean and rely on view->output to specify the
output.
Along the way, change a few related usages of struct wlr_output to
struct output as well.
No functional change intended.
v2: Don't allow entering fullscreen on disabled output (makes
conditions for entering/leaving fullscreen symmetric)
v3: Use output_is_usable() helper
view->impl->move() is a specific case of view->impl->configure().
To reduce code duplication, we can use view->impl->configure() for
pure moves (without resize) as well.
xwayland's move() function also possibly contained a race condition
when there was a pending resize, as it used the current surface
width/height rather than the pending width/height. This is fixed.
It was not working before because in the case of wayland
we are only dealing with sizes as wayland has no notion
of a global position. A wayland client would thus not
necessarily respond to a configure request which sets
the same size again. This causes us to also not apply
a new position set in view->pending because there may
be no commit from the client in those cases.
We previously worked around this issue in some parts
of the code to check our new sizes against the pending
ones and if they were the same we would call view_move
instead. That had two issues:
- Not all parts of the code did that which could end up
delaying the positioning either to the next completely
unrelated xdg commit event or to the next view_move call
- The code started to repeat itself, e.g. the same condition
with calls to either view_move or view_move_resize based
on the result
This patch fixes it by doing the check in the xdg configure
handler instead. Xwayland is unaffected by this issue as we
are always configuring a xwayland client with both, position
and size.
