Make floating windows spawn within the monitor's window area
This is a follow-up on this thread:
https://lists.suckless.org/hackers/2208/18462.html
The orginal code had constraints such that if a window's starting
attributes (position and size) were to place the window outside of
the edges of the monitor, then the window would be moved into view
at the closest monitor edge.
There was an exception to this where if a top bar is used then the
window should not obscure the bar if present, which meant to place
the window within the window area instead.
The proposed change here makes it the general rule that floating
windows should spawn within the window area rather than within the
monitor area. This makes it simple and consistent with no
exceptions and it makes the intention of the code clear.
This has the benefit of making the behaviour consistent regardless
of whether the user is using a top bar or a bottom bar.
Additionally this will have an effect on patches that modify the
size of the window area. For example if the insets patch is used to
reserve space on the left hand side of the monitor for a dock or a
vertical bar then new floating clients will not obscure that area.
Ref.
https://git.suckless.org/dwm/commit/44adafe0069e73aa03a3829d7bb39591cd8b3f1d.html
code-style: simplify some checks
main change here is making the `zoom()` logic saner. the rest of the
changes are just small stuff which accumulated on my local branch.
pop() must not be called with NULL. and `zoom()` achieves this, but in a
very (unnecessarily) complicated way:
if c == NULL then nexttiled() will return NULL as well, so we enter this
branch:
if (c == nexttiled(selmon->clients))
in here the !c check fails and the function returns before calling pop()
if (!c || !(c = nexttiled(c->next)))
return;
however, none of this was needed. we can simply return early if c was NULL.
Also `c` is set to `selmon->sel` so we can use `c` in the first check
instead which makes things shorter.
Ref.
https://git.suckless.org/dwm/commit/5e76e7e21da042c493c59235ca82d7275f20a7e4.html
This is in particular to avoid flickering in dwm (and high CPU usage)
when hovering the mouse over a tabbed window that was previously
managed by dwm.
Consider the following two scenarios:
1)
We start tabbed (window 0xc000003), tabbed is managed by the
window manager.
We start st being embedded into tabbed.
$ st -w 0xc000003
What happens here is that:
- tabbed gets a MapRequest for the st window
- tabbed reparents the st window
- tabbed will receive X events for the window
The window manager will have no awareness of the st window and the
X server will not send X events to the window manager relating to
the st window.
There is no flickering or any other issues relating to focus.
2)
We start tabbed (window 0xc000003), tabbed is managed by the
window manager.
We start st as normal (window 0xd400005).
What happens here is that:
- the window manager gets a MapRequest for the st window
- dwm manages the st window as a normal client
- dwm will receive X events for the window
Now we use xdotool to trigger a reparenting of the st window into
tabbed.
$ xdotool windowreparent 0xd400005 0xc000003
What happens here is that:
- tabbed gets a MapRequest for the st window
- tabbed reparents the st window
- the window manager gets an UnmapNotify
- the window manager no longer manages the st window
- both the window manager and tabbed will receive X events
for the st window
In dwm move the mouse cursor over the tabbed window.
What happens now is that:
- dwm will receive a FocusIn event for the tabbed window
- dwm will set input focus for the tabbed window
- tabbed will receive a FocusIn event for the main window
- tabbed will give focus to the window on the currently selected
tab
- which again triggers a FocusIn event which dwm receives
- dwm determines that the window that the FocusIn event is for
(0xd400005) is not the currently selected client (tabbed)
- dwm sets input focus for the tabbed window
- this causes an infinite loop as long as the mouse cursor hovers
the tabbed window, resulting in flickering and high CPU usage
The fix here is to tell the X server that we are no longer interested
in receiving events for this window when the window manager stops
managing the window.
When monitors are removed, the coordinates of existing monitors may
change, if the removed monitors had smaller coordinates than the
remaining ones.
Remove special case handling so that the same update-if-necessary loop
is run also in the case when monitors are removed.
ref.
https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html#h0-0-21
This patch defers all size hint calculations until they are actually
needed, drastically reducing the number of calls to updatesizehints(),
which can be expensive when called repeatedly (as it currently is during
resizes).
In my unscientific testing this reduces calls to updatesizehints() by
over 90% during a typical work session. There are no functional changes
for users other than an increase in responsiveness after resizes and
a reduction in CPU time.
In slower environments or X servers, this patch also offers an
improvement in responsiveness that is often tangible after resizing a
client that changes hints during resizes.
There are two main motivations to defer this work to the time of hint
application:
1. Some clients, especially terminals using incremental size hints,
resend XA_WM_NORMAL_HINTS events on resize to avoid fighting with the
WM or mouse resizing. For example, some terminals like urxvt clear
PBaseSize and PResizeInc during XResizeWindow and restore them
afterwards.
For this reason, after the resize is concluded, we typically receive
a backlogged XA_WM_NORMAL_HINTS message for each update period with
movement, which is useless. In some cases one may get hundreds or
thousands of XA_WM_NORMAL_HINTS messages on large resizes, and
currently all of these result in a separate updatesizehints() call,
of which all but the final one are immediately outdated.
(We can't just blindly discard these messages during resizes like we
do for EnterNotify, because some of them might actually be for other
windows, and may not be XA_WM_NORMAL_HINTS events.)
2. For users which use resizehints=0 most of these updates are unused
anyway -- in the normal case where the client is not floating these
values won't be used, so there's no need to calculate them up front.
A synthetic test using the mouse to resize a floating terminal window
from roughly 256x256 to 1024x1024 and back again shows that the number
of calls to updatesizehints() goes from over 500 before this patch (one
for each update interval with movement) to 2 after this patch (one for
each hint application), with no change in user visible behaviour.
This also reduces the delay before dwm is ready to process new events
again after a large resize on such a client, as it avoids the thundering
herd of updatesizehints() calls when hundreds of backlogged
XA_WM_NORMAL_HINTS messages appear at once after a resize is finished.
ref.
https://git.suckless.org/dwm/commit/8806b6e2379372900e3d9e0bf6604bc7f727350b.html#h0-0-4
In certain instances trans may be set to a window that doesn't actually
map to a client via wintoclient; in this case it doesn't make sense
to set isfloating/oldstate since trans is essentially invalid in that
case / correlates to the above condition check where trans is set /
XGetTransientForHint is called.
Ref.
https://git.suckless.org/dwm/commit/bece862a0fc4fc18ef9065b18cd28e2032d0d975.html
+ when moving window from monitor with different tags selected the moved
window would not get the tags set properly if multiple windows are
already on that monitor
