Chris Down [Sat, 18 Dec 2021 16:58:23 +0000 (16:58 +0000)]
drawbar: Don't expend effort drawing bar if it is occluded
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().
Miles Alan [Mon, 9 Aug 2021 16:24:14 +0000 (18:24 +0200)]
Improve speed of drw_text when provided with large strings
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.
Chris Down [Thu, 2 Jul 2020 19:18:30 +0000 (20:18 +0100)]
Do not allow focus to drift from fullscreen client via focusstack()
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.
dwm crashes when opening 50+ clients (tile layout)
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.
Chris Down [Wed, 22 Apr 2020 14:48:27 +0000 (15:48 +0100)]
drawbar: Don't shadow sw global
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.
Chris Down [Mon, 20 Apr 2020 15:41:52 +0000 (16:41 +0100)]
setmfact: Unify bounds for compile-time and runtime mfact
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.
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.
Markus Teich [Sat, 7 Jan 2017 16:21:29 +0000 (17:21 +0100)]
Button passthrough when client is not focused
Before this change it is not possible to press a button in a client on the first
click if the client is not yet focused. The first click on the button would
only focus the client and a second click on the button is needed to activate it.
This situation can occur when moving the mouse over a client (therefore focusing
it) and then moving the focus to another client with keyboard shortcuts.
After this commit the behavior is fixed and button presses on unfocused clients
are passed to the client correctly.
Markus Teich [Sat, 7 Jan 2017 16:21:28 +0000 (17:21 +0100)]
cleanup
- unify multi-line expression alignment style.
- unify multi-line function call alignment style.
- simplify client moving on monitor count decrease.
- clarify comment for focusin().
- remove old confusing comment about input focus fix in focusmon(). The
explanation is already in the old commit message, so no need to keep it in the
code.
- remove old comment describing even older state of the code in focus().
- unify comment style.
- break up some long lines.
- fix some typos and grammar.
Eric Pruitt [Wed, 25 May 2016 23:33:11 +0000 (16:33 -0700)]
Configure geometry before applying rules
Configuring geometry before applying rules makes it possible to have
more complex constraints in applyrules that depend on the initial window
dimensions and location.
Quentin Rameau [Sat, 7 Nov 2015 13:09:08 +0000 (14:09 +0100)]
setfullscreen: don't process the property twice
Some clients try to set _NET_WM_STATE_FULLSCREEN even when the window is
already in fullscreen.
For example, c->oldstate was set two times in a raw and window would
then always be floating.
We must check that it's not the case before processing it.
(original patch modified with suggestion from Markus Teich
<markus.teich@stusta.mhn.de>)
Anselm R Garbe [Mon, 11 Aug 2014 05:24:29 +0000 (07:24 +0200)]
applied Hiltjo's resize/move limitation
"Limit the amount of updates when resizing or moving a window in floating
mode to 60 times per second. This makes resizing and moving alot smoother
and by limiting it it also uses alot less resources on my machine.
anselm@garbe.us [Sat, 23 Jun 2012 07:06:00 +0000 (09:06 +0200)]
reversed Andreas Amann's fullscreen fix with the approach proposed by Gary Langshaw:
- idea is not supporting movemouse/resizemouse/togglefloating for fullscreen windows
- as fullscreen windows are broken anyways, they should only be adjusted by their own means