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.
Currently, labwc automatically enables outputs at startup and when new
outputs are connected. Make this behavior optional (but still enabled by
default).
With autoEnableOutputs disabled, tools such as kanshi can be used to
give finer-grained control of which outputs are enabled and when.
...to WLR_INFO to avoid logging issues with .desktop files as errors, for
example:
[sfdo-desktop] 1:1: Name is unset
[sfdo-desktop] Failed to load /usr/share/applications/lxqt-panel.desktop
[sfdo-desktop] 1:1: Exec is unset while DBusActivatable is unset or false
[sfdo-desktop] Failed to load /usr/share/applications/qemu.desktop
Also make libsfdo debug/info logging depend on environment variable
LABWC_DEBUG_LIBSFDO being set to avoid disproportionately verbose logging
by default for one particular sub-system.
Add an 'ENVIRONMENT VARIABLES' section to labwc(1) to describe the above
as well as other hitherto undocumented env vars with prefix LABWC_DEBUG_.
...to avoid surprises on Acer Aspire One laptops where the numeric
keyboard does not physically exist but "overlaps" the qwerty keyboard.
Reported-by: staryvyr on IRC
Note: We do not like changing defaults, but feel that there is a good
reason for this one.
This is a compile-time check, so it will be too conservative if somebody
updates wlroots after building labwc, but that is still better than the
alternatives.
...to avoid a bug that is present in wlroots <0.18.2 and which has the
potential to crash the compositor when performing a drag-and-drop action
at the same time as the XWayland server is shutting down.
This will be reverted when wlroots-0.18.2 can be linked with.
Related-to: #2371
...of modifiers which are part of keybinds. This supports clients (for
example blender) that want to see modifier-release-events even if they are
part of a keybinds.
Most clients (including those using Qt and GTK) are setup to not see these
modifier release events and actually misbehave if they do. For example
Firefox shows the menu bar if alt is pressed and then released, whereas if
only pressed (because the release is absorbed) nothing happens. So, if
Firefox saw bound modifier-release-events it would show the menu bar every
time the window-switcher is used with alt-tab.
<windowRules>
<windowRule identifier="blender" wantAbsorbedModifierReleaseEvents="yes"/>
</windowRules>
Issue #1507
This makes the colors of titlebar and window borders different, but will
let menu.border.color (which will be supported soon) inherit
window.active.border.color just like Openbox does, without making the menu
borders around a selected menu item invisible.
...to guard against recursive constructs like FOO=$FOO:bar which would
grow on each reconfigure.
Add log message as well as a warning against this in the man page.
...to replace padding.{width,height} to minimize breaking changes with the
visual appearance of the titlebar.
With the diverging labwc specification for the titlebar (listed below)
we have to choose between (a) not supporting the padding.{width,height}
option which exist in many extant Openbox themes to keep titlebar height
(almost) the same; or (b) making the allocated button areas much smaller
and not keeping the default hover going all the way to the edges. All in
all it just seems a lot simpler and cleaner to break this link to the
openbox spec.
Examples of previous change driving the requirement for this change:
- SVG and PNG support which often results in large icons with hover
effects.
- Theme option window.button.{height,width}
- Larger default areas for icons (26x26)
In way of an example, Numix theme sets a padding.height of 6 which would
have resulted in a titlebar 12px taller without this change.
...because now that window.button.height determines the height of button
hover effect the visible appearance of the titlebar will change unless
we reduce the padding to zero.
Backward compatibility notice: If a users theme sets padding.height to a
value greater than zero, the titlebar will be taller compared with
openbox. This can be fixed by either reducing window.button.height or
overriding padding.height
This theme setting does not exist in Openbox spec and has just been an
additional 'knob' to tweak the height which is otherwise derived from the
sizes of the objects within it plus padding.
The default `titleLayout` is updated to `icon:iconify,max,close` which
replaces the window menu button with the window icon.
When the icon file is not found or could not be loaded, the window menu
icon as before is shown.
The icon theme can be selected with `<theme><icon>`.
This commit adds libsfdo as an optional dependency. `-Dicon=disabled` can
be passsed to `meson setup` command in order to disable window icon, in
which case the window icon is always replaced with a window menu button.
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
