Unlike with X window managers, the display socket in Wayland isn't set
up prior to starting the compositor. Because of this, you can't pipe
the compositor's output directly into a program which needs access to
$WAYLAND_DISPLAY, which is a typical setup for this purpose. Existing
scripts have been forced to create a pipe/FIFO or a temporary file as an
intermediary.
Instead, send the status info directly to stdin of the -s command, which
*does* have access to $WAYLAND_DISPLAY.
Fixes#103.
Fixes#102. The "ideal" behavior might be to ignore buttons other than
the one being used for the action, but this is super-simple and still
seems reasonable.
The wlr-output-management protocol requires that either all of the
changes from an apply request be applied successfully, in which case a
"succeeded" event is sent, or all of the changes are reverted and a
"failed" event is sent. As written, this could partially commit
changes, then fail.
Test the changes first (even for an "apply" event), then commit or
rollback as appropriate.
Additionally, variables xcursor and xcursor_mgr are only used
when xwayland is defined, so I make the variables declaration
contingent on whether xwayland is being used
Replaces the outputOrder patch.
This avoids recalculating positions and allows to arrange monitors in
any order, not just from left to right.
The order in which monitors are defined in config.h still matters but
it's just the order in the list, not the actual position.
This is the order of *_destroy calls which resulted in the fewest
errors/leaks detected by Valgrind. Most of the errors come from the
gbm_allocator code - will have to figure out which destroy call is still
missing.
Similar to Linux kernel approach, encapsulate some of the uglier
conditional compilation into inline functions in header files.
The goal is to make dwl.c more attractive to people who embrace the
suckless philosophy - simple, short, hackable, and easy to understand.
We want dwm users to feel comfortable here, not scare them off. Plus,
if we do this right, the main dwl.c code should require only minimal
changes once XWayland is no longer a necessary evil.
According to `cloc`, this also brings dwl.c down below 2000 lines of
non-blank, non-comment code.