| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
With this commit, each tag has two gap values (indexes at
`gaps_previous`, `gaps_current`) that can be interchanged via
`toggle_gaps`. At initialisation, `gaps_previous` is set to
`default_gaps` and `gaps_current` is set to all 0.
|
|
|
|
focus(NULL) is called when switching to a new tag or monitor. I don't
want sticky windows to get first focus in this situation, hence this
code. Shamelessly stolen from
https://github.com/LukeSmithxyz/dwm/issues/152.
|
|
Make sticky windows, which are kinda like Mod-Shift-0 tagged windows
but easier to manage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For each tag there is a gap (set to the default gappx on
construction). When adjusting gaps or arranging a monitor use the
gaps of the currently selected tag. This means I can have gaps
activated in some tags and not activated on others.
|
|
Obsolete due to previous patch
|
|
If using an external keyboard client such as sxhkdrc then dwm has no
business or need to spawn something like dmenu.
|
|
|
|
This will provide up to date references to my key bindings!
|
|
|
|
|
|
|
|
This adjusts both the x and y of each client now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Laptop had gapless grid
|
|
|
|
|
|
Using normal dwm mechanisms for now
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
SA_NOCLDWAIT is marked as XSI in the posix spec [0] and FreeBSD and NetBSD
seems to more be strict about the feature test macro [1].
so update the macro to use _XOPEN_SOURCE=700L instead, which is equivalent to
_POSIX_C_SOURCE=200809L except that it also unlocks the X/Open System
Interfaces.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html#tag_13_42
[1]: https://lists.suckless.org/dev/2302/35111.html
Tested on:
* NetBSD 9.3 (fixed).
* FreeBSD 13 (fixed).
* Void Linux musl.
* Void Linux glibc.
* OpenBSD 7.2 (stable).
* Slackware 11.
Reported-by: beastie <pufferfish@riseup.net>
|
|
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
|
|
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
|
|
This reverts commit c2b748e7931e5f28984efc236f9b1a212dbc65e8.
Revert back this change. It seems to not be an edge-case anymore since
multiple users have asked about this new behaviour now.
|
|
|
