The Makefile used to suppress output (by using @), so this target made sense at
the time.
But the Makefile should be simple and make debugging with less abstractions or
fancy printing. The Makefile was made verbose and doesn't hide the build
output, so remove this target.
Prompted by a question on the mailing list about the options target.
ref.
https://git.suckless.org/dwm/commit/9f8855343c881bdc01b9fff5b956537ba1106b76.html
restore SIGCHLD sighandler to default before spawning a program
From sigaction(2):
A child created via fork(2) inherits a copy of its parent's signal dispositions.
During an execve(2), the dispositions of handled signals are reset to the default;
the dispositions of ignored signals are left unchanged.
This refused to start directly some programs from configuring in config.h:
static Key keys[] = {
MODKEY, XK_o, spawn, {.v = cmd } },
};
Some reported programs that didn't start were: mpv, anki, dmenu_extended.
Reported by pfx.
Initial patch suggestion by Storkman.
Ref.
https://git.suckless.org/dwm/commit/e81f17d4c196aaed6893fd4beed49991caa3e2a4.html
Changes to core utils had the side effect of treating the no-clobber option
as an error if the file was not copied if it already exists, thus causing
make to error as well.
Adding this workaround until that issue is addressed.
Alternative solutions:
- always overwrite the file using the -f / --force option
- prefix the cp command with a hyphen which will cause make to ignore
the error, but still report it
- never copy dwm.desktop during the installation process
* Add swallow/window icon compatibility. Without this, after a client is
swallowed the old icon (usually from the terminal emulator) is
preserved. This is noticeable if you, say run `mpv` from a terminal
emulator which is a common use case.
---------
Co-authored-by: speedie <speedie@duck.com>
Use sigaction(SA_NOCLDWAIT) for SIGCHLD handling
signal() semantics are pretty unclearly specified. For example, depending on OS
kernel and libc, the handler may be returned to SIG_DFL (hence the inner call
to read the signal handler). Moving to sigaction() means the behaviour is
consistently defined.
Using SA_NOCLDWAIT also allows us to avoid calling the non-reentrant function
die() in the handler.
Some addditional notes for archival purposes:
* NRK pointed out errno of waitpid could also theoretically get clobbered.
* The original patch was iterated on and modified by NRK and Hiltjo:
* SIG_DFL was changed to SIG_IGN, this is required, atleast on older systems
such as tested on Slackware 11.
* signals are not blocked using sigprocmask, because in theory it would
briefly for example also ignore a SIGTERM signal. It is OK if waitpid() is (in
theory interrupted).
POSIX reference:
"Consequences of Process Termination":
https://pubs.opengroup.org/onlinepubs/9699919799/functions/_Exit.html#tag_16_01_03_01
Ref. https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
NB: Cool autostart patch to use prior logic for now
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
