CycleInRegion will cycle focus between all windows/views that are within
the given region, to support position-based focusing.
The window/region matching supports:
* when a window is explicitly assigned to a region
* an optional `windowOverlapPercentage` arg, when at least the given
percentage of the window's geometry is within the region's geometry.
* an optional `regionOverlapPercentage` arg, when at least the given
percentage of the region's geometry is within the window's geometry.
To support immediate focus cycling and to avoid ping-pong'ing between the
top two windows, we cycle through windows within a region in
reverse-order. When we are not focused within a region, we instead focus
the top-most (first) window, as that is what the user will expect.
If the `region` arg is not specified, the action will cycle through all
windows on the given desktop instead.
This introduces an optional "direction" argument to the Resize action,
mirroring Fluxbox's StartResizing [corner] behavior.
Supported values (case-insensitive) are:
up-left, up, up-right, left, right, down-left, down, down-right.
If no direction is specified, the existing behavior is preserved and the
resize edges are inferred from the current pointer position. The action
documentation has been updated to describe the new argument.
This patch adds `combine` argument to (Toggle)SnapToEdge actions.
This allows to snap a window to e.g. up-left by running two actions:
- `<action name="SnapToEdge" direction="left" combine="yes" />`
- `<action name="SnapToEdge" direction="up" combine="yes" />`
Then running `<action name="SnapToEdge" direction="down" combine="yes" />`
snaps it to left again. This behavior is almost the same as KWin, except
that snapping a up-right-tiled window to right doesn't move it to the
right-adjacent output, but makes it right-tiled first.
Adds an option "toogle" to GoToDesktop.
In case the target is already where we are, we go back to the last desktop
instead.
Example of rc.xml
<keybind key="C-F1">
<action name="GoToDesktop">
<to>1</to>
<toggle>yes</toggle>
</action>
</keybind>
In addition to <snapping><range>, <snapping><cornerRange> configures the
distance from the screen corner to trigger quater window snapping.
Also, new values "up-left", "up-right", "down-left" and "down-right" are
allowed for <action name="(Toggle)SnapToEdge" direction="[value]"> and
<query tiled="[value]">.
Before this commit, keystrokes were interpreted based on following
hard-coded rules while the window switcher is active:
1. Up/Left arrow keys cycle the window forward.
2. Down/Right arrow keys cycle the window backward.
3. Other keystrokes cycle the window in the initial direction specified
by NextWindow/PreviousWindow actions. But while Shift key is pressed,
the direction is inverted.
...and keybind actions were never executed.
However, this lead to a counter-intuitive behavior for new, especially
pre-Openbox users. For example, in the following keybinds, after the user
activates the window switcher with Super+n, Super+p cycles the window
_forward_:
<keybind key="W-n">
<action name="NextWindow" />
</keybind>
<keybind key="W-p">
<action name="PreviousWindow" />
</keybind>
This is because the key 'n' is recognized just as a normal key in the
third hard-coded rule.
So this commit changes the rules to be more Openbox-like:
1. Up/Left arrow keys cycles the window forward.
2. Down/Right arrow keys cycles the window backward.
3. Other keystrokes are matched against keybinds and execute their
actions. If they include NextWindow/PreviousWindow action, it cycles
the selected window forward/backward even while the window switcher
is active.
Behaves identical like SnapToEdge and SnapToRegion, but
untiles the window when already being tiled to the given
region or direction.
Co-authored-by: tokyo4j <hrak1529@gmail.com>
Shows all workspaces that current view can be sent to.
Works best when added to Client menu.
<menu id="client-send-to-menu" label="Send to..." />
Menu uses ">" and "<" to highlight the current workspace
...utilizing x,y coordinates where values can be a number, a negative
number, a percentage or "center".
- (0,0) is top left corner
- (-0,-0) is bottom right corner
- % is percentage of width and/or height
- 'center' centers the menu vertically and/or horizontally
<action name="ShowMenu">
<menu>root-menu</menu>
<position>
<x>0</x>
<y>0</y>
</position>
</action>
Note: both x and y values must be supplied for positioning to work.
Adds following settings:
<placement>
<policy>cascade</policy>
<cascadeOffset x="40" y="30" />
</placement>
"Cascade" policy places a new window at the center of the screen like
"center" policy, but possibly shifts its position to bottom-right so the
new window doesn't cover existing windows.
The algorithm is copied from KWin's implementation:
df9f8f8346/src/placement.cpp (L589)
Also added some helper functions to manipulate `wlr_box`.
...when cycling windows. Also make the toggling of direction when shift
is pressed relative to the initial direction. For example if W-j is
bound to PreviousWindow, subsequent key presses will continue to
cycle backwards unless shift if pressed.
Add documentation for using shift/arrow keys in Next/Previous
This adds a screen magnifier which can be controlled with the
`ZoomIn` / `ZoomOut` and `ToggleMagnify` actions.
It scales up part of the rendered framebuffer so the magnification
may end up looking blurry depending on the magnification scale.
PR #1774
We were using the argument name 'name' before
which is already used by the action itself:
`<action name="MoveToOutput" name="HDMI-A-1" />`
Change the argument name to "output" which also
matches the `FocusOutput` action.
Fixes: #1589
Reported-by: @bnason (thanks!)
Support `wrap` in view_get_adjacent_output(). This means that when seeking
an adjacent output in a particular direction from an output that is
already furthest in that direction within the layout, rather than
returning NULL, wrap around from the leftmost to the rightmost, or topmost
to the bottommost and vice versa.
Example usage:
<action name="MoveToOutput" direction="right" wrap="yes" />
Wrap is disabled by default to keep the user interface consistent.
This builds on the work of @Consolatis in #1018.
Co-authored-by: Consolatis <35009135+Consolatis@users.noreply.github.com>
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>