Text width calculations when using status2d strings resulted in
statuscmd button placement calculations to be way off. Fixed by
introducing a separate function status2dtextlength to get an
approximate correct text width.
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.
This is an updated version of the statuscolors patch that fixes the
computation of the text width. The previous version of the patch
inculded all the byte codes that are used to select the color schemes
when computing the width, obaining a width that is larger than the real
width. This patch fixes that by adding up the widths of the individual
chunks, separated by the codes that select the color schemes.
This patch enables multiple scratchpads, each with one assigned 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 the 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 on
the selected scratchpad. 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).
bakkeby