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.
When a new client is spawned, fullscreen isn't disabled for all clients
in that monitor any more.
Instead, all fullscreen clients are kept fullscreen, while other clients
spawn in the background.
When fullscreen is disabled, all clients are rearranged.
This is made to make dwl more flexible allowing multiple fullscreen
clients at the same time, have floating clients on top of a fullscreen
one and let stuff happen without quitting fullscreen, like many other
WMs and DEs.
Disable fullscreen on all visible clients in that monitor also before
enabling it on another client.
quitallfullscreen() is reintroduced becouse is now more useful
set c->isfullscreen later to avoid making quitallfullscreen() disable
fullscreen on the current client
...in internal calls to restore pointer focus. Necessary for the
unclutter patch, and there's no harm in avoiding this call even in
mainline; might prevents issues in same edge cases.
- A maximum SLOC can't be reasonably determined before implementing the
missing protocols, so not any time soon
- dwl definitely isn't a simple as dwm since it must implement lots of
Wayland protocols and not just manage windows. The status bar
integration, layer shell popups, damage tracking and IME are gonna
require hundreds more lines each.
- "Buffering of input when spawning a client so you don't have to wait
for the window (use `wl_client_get_credentials` to get the PID) - would
this require passing through something like dmenu? Extension protocol?"
This sounds exoteric, if anything this should be patch.
- Can dwl really be started from within an X session? When I do it from
dwm it crashes.
- A window's texture is scaled for its "home" monitor only (noticeable
when window sits across a monitor boundary)
Gonna open a ticket for this rather than keep it in the README.
