The reasoning behind the original line may be lost to time as
it does not make much sense checking the position on the x-axis
to determine how to position the client on the y-axis.
In the context of multi-monitor setups the monitor y position
(m->my) may be greater than 0 (say 500), in which case the window
could be placed out of view if:
- the window attributes have a 0 value for the y position and
- we end up using the y position of bh (e.g. 22)
If the aim is to avoid a new floating client covering the bar then
restricting y position to be at least that of the window area
(m->wy) should cover the two cases of using a top bar and using a
bottom bar.
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.
when calling die and the last character of the string corresponds to
':', die() will call perror(). See util.c
Also change EXIT_SUCCESS to EXIT_FAILURE
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.