By default, dwm response to client requests to _NET_ACTIVE_WINDOW client
messages by setting the urgency bit on the named window.
This patch activates the window instead.
Both behaviours are legitimate according to
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472702304
One should decide which of these one should perform based on the message
senders' untestable claims that it represents the end-user. Setting the
urgency bit is the conservative decision. This patch implements the more
trusting alternative.
It also allows dwm to work with `wmctrl -a` and other external window
management utilities.
This patch enables multiple scratchpads, each with one asigned window.
This enables the same scratchpad workflow that you have in i3.
Scratchpads are implemented as special tags, whose mask does not
apply to new spawned windows. To assign a window to a scratchpad you
have to set up a rule, as you do with regular tags.
Windows tagged with scratchpad tags can be set floating or not in the
rules array. Most users would probably want them floating (i3 style),
but having them tiled does also perfectly work and might fit better the
DWM approach. In case they are set floating, the patch moves them to the
center of the screen whenever they are shown. The patch can easily be
modified to make this last feature configurable in the rules array (see
the center patch).
The togglescratch function, borrowed from the previous scratchpad patch
and slightly modified, can be used to spawn a registered scratchpad
process or toggle its view. This function looks for a window tagged with
the selected scratchpad tag. If it is found its view is toggled. If it is
not found the corresponding registered command is spawned. The
config.def.h shows three examples of its use to spawn a terminal in the
first scratchpad tag, a second terminal running ranger on the second
scratchpad tag and the keepassxc application to manage passwords on a
third scratchpad tag.
If you prefer to spawn your scratchpad applications from the startup
script, you might opt for binding keys to toggleview instead, as
scratchpads are just special tags (you may even extend the TAGKEYS macro
to generalize the key bindings).
I noticed that a non-trivial amount of dwm's work on my machine was from
drw_text, which seemed weird, because I have the bar disabled and we
only use drw_text as part of bar drawing.
Looking more closely, I realised that while we use m->showbar when
updating the monitor bar margins, but don't skip actually drawing the
bar if it is hidden. This patch skips drawing it entirely if that is the
case.
On my machine, this takes 10% of dwm's on-CPU time, primarily from
restack() and focus().
When the bar is toggled on again, the X server will generate an Expose
event, and we'll redraw the bar as normal as part of expose().
This reverts commit 716233534b.
It causes issues with truncation of characters when the text does not fit and
so on. The patch should be reworked and properly tested.
Calculates len & ew in drw_font_getexts loop by incrementing instead of
decrementing; as such avoids proportional increase in time spent in loop
based on provided strings size.
It generally doesn't make much sense to allow focusstack() to navigate
away from the selected fullscreen client, as you can't even see which
client you're selecting behind it.
I have had this up for a while on the wiki as a separate patch[0], but
it seems reasonable to avoid this behaviour in dwm mainline, since I'm
struggling to think of any reason to navigate away from a fullscreen
client other than a mistake.
0: https://dwm.suckless.org/patches/alwaysfullscreen/
Many users new to dwm find themselves caught out by being kicked out to the login manager (dwm crashing) when they open 50+ clients for demonstration purposes. The number of clients reported varies depending on the resolution of the monitor.
The cause of this is due to how the default tile layout calculates the height of the next client based on the position of the previous client. Because clients have a minimum size the (ty) position can exceed that of the window height, resulting in (m->wh - ty) becoming negative. The negative height stored as an unsigned int results in a very large height ultimately resulting in dwm crashing.
This patch adds safeguards to prevent the ty and my positions from exceeding that of the window height.
This jarred me a bit while reading the code, since "sw" usually refers
to the global screen geometry, but in drawbar() only it refers to
text-related geometry. Renaming it makes it more obvious that these are
not related.
There are two places that mfact can be set:
- In the mfact global, which is defined at compile time and passed
into m->mfact during monitor setup. No bounds checks are performed,
but the comment alongside it says that valid values are [0.05..0.95]:
static const float mfact = 0.55; /* factor of master area size [0.05..0.95] */
- By setmfact, which adjusts m->mfact at runtime. It also does some
minimum and maximum bounds checks, allowing [0.1..0.9]. Values outside
of that range are ignored, and mfact is not adjusted.
These different thresholds mean that one cannot setmfact 0.95 or 0.05,
despite the comment above that lists the legal range for mfact.
Clarify this by enforcing the same bounds in setmfact at runtime as
those listed for mfact at compile time.
In dwm.c function declarations are in alphabetical order except for
updategeom(). There doesn't appear to be any reason for this, so this
patch corrects that, and now all function declarations are in
alphabetical order.
Reported by Kernc, thanks!
"This makes a particular program that uses libwnck [1] fail after:
Wnck-WARNING **: Property _NET_WM_NAME contained invalid UTF-8
in this code [2] because the returned string contains a '\0' and the
documentation for g_utf8_validate() [3] explicitly states that when
string length is provided, no nul bytes are allowed."
It is not entirely clear it is incorrect, other WM's seem to not
NUL terminate it either though.
