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().
Ref. https://git.suckless.org/dwm/commit/8657affa2a61e85ca8df76b62e43cb02897d1d80.html
consideration when deciding whether or not to allow dwm to quit
As per the original patch
https://dwm.suckless.org/patches/onlyquitonempty/
it used XQueryTree to get a count of the number of windows open to
determine whether to allow the window manager to exit.
This meant that the empty quit count variable would have to take
into account background windows such as the bar, which has side
effects like plugging in another monitor could mean that you would
not longer be allowed to quit dwm until the monitor is removed.
Likewise a systray and each systray icon would give a +1 to the
number of windows in the system.
This is unintuitive to understand and convoluted to explain, hence
the refactoring here to use the more sane approach of only counting
the number of client windows that the window manager manages.
This is an old idea which was intentionally not added to
dwm-flexipatch due to the aim of staying true to the original patch
(as in if you were to patch that manually you would get the same
experience as you had when trying the patch out in dwm-flexipatch).
This is ref. discussion in #194.
The original statuscmd patch has been renamed to statuscmd-nosignal
to separate the logic from the dwmblocks integration that involves
signals. I assume as the latter has become more popular it has replaced
the statuscmd in name.
