grabkeys: Avoid missing events when a keysym maps to multiple keycodes
It's not uncommon for one keysym to map to multiple keycodes. For
example, the "play" button on my keyboard sends keycode 172, but my
bluetooth headphones send keycode 208, both of which map back to
XF86AudioPlay:
% xmodmap -pke | grep XF86AudioPlay
keycode 172 = XF86AudioPlay XF86AudioPause XF86AudioPlay XF86AudioPause
keycode 208 = XF86AudioPlay NoSymbol XF86AudioPlay
keycode 215 = XF86AudioPlay NoSymbol XF86AudioPlay
This is a problem because the current code only grabs a single one of
these keycodes, which means that events for any other keycode also
mapping to the bound keysym will not be handled by dwm. In my case, this
means that binding XF86AudioPlay does the right thing and correctly
handles my keyboard's keys, but does nothing on my headphones. I'm not
the only person affected by this, there are other reports[0].
In order to fix this, we look at the mappings between keycodes and
keysyms at grabkeys() time and pick out all matching keycodes rather
than just the first one. The keypress() side of this doesn't need any
changes because the keycode gets converted back to a canonical keysym
before any action is taken.
0: https://github.com/cdown/dwm/issues/11
Ref.
https://git.suckless.org/dwm/commit/89f9905714c1c1b2e8b09986dfbeca15b68d8af8.html
An example problematic situation would be to open a YouTube video
in Google Chrome and making that video fullscreen. Without this fix
the window will go into fullscreen within its tiled dimension, but
the size of the video will match that of the screen (and it will
be cropped).
With this fix the window will be resized which nudges the
application to adjust the fullscreen size accordingly.
Remove dmenumon variable
Reasoning: Since 2011 dmenu has been capable of working out which
monitor currently has focus in a Xinerama setup, making the use
of the -m flag more or less redundant.
This is easily demonstrated by using dmenu in any other window
manager.
There used to be a nodmenu patch that provided these changes:
https://git.suckless.org/sites/commit/ed68e3629de4ef2ca2d3f8893a79fb570b4c0cbc.html
but this was removed on the basis that it was very easy to work
out and apply manually if needed.
The proposal here is to remove this dependency from dwm. The
mechanism of the dmenumon variable could be provided via a patch
if need be.
The edge case scenario that dmenu does not handle on its own, and
the effect of removing this mechanism, is that if the user trigger
focusmon via keybindings to change focus to another monitor that
has no clients, then dmenu will open on the monitor containing the
window with input focus (or the monitor with the mouse cursor if
no windows have input focus).
If this edge case is important to cover then this can be addressed
by setting input focus to selmon->barwin in the focus function if
there is no client to give focus to (rather than giving focus back
to the root window).
Ref.
https://git.suckless.org/dwm/commit/c2b748e7931e5f28984efc236f9b1a212dbc65e8.html
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.
bakkeby
monosans