Commit Graph

1735 Commits

Author SHA1 Message Date
David JULIEN 36a8e80ee2 feat: restoreadterrestart patch 2023-01-08 18:11:51 +01:00
David JULIEN 4a476e877c feat: restartsig patch 2023-01-08 15:02:34 +01:00
David JULIEN 16bc69ce1c
Merge branch 'upstream'
update to 6.4
2023-01-08 15:00:38 +01:00
David JULIEN 115058faa8 feat: window selborder gets its own variable 2023-01-08 00:23:43 +01:00
Chris Down 89f9905714 grabkeys: Avoid missing events when a keysym maps to multiple keycodes
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

    % 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.

2022-12-07 23:06:26 +01:00
David JULIEN 4af8e13709 fix: fonts array
fonts not in the array couldn't be tweaked through xrdb
2022-11-04 20:56:14 +01:00
David JULIEN aa43e52021 fix 1b6b09b : make pinentry-gtk-3 floating window 2022-11-04 18:51:25 +01:00
David JULIEN 89d751ef3a feat: support japanese symbols 2022-11-01 23:25:24 +01:00
David JULIEN ad4ddc40f3 feat: normbordercolor makes cindows dinstinguishable 2022-10-31 15:54:27 +01:00
Hiltjo Posthuma ba56fe9fea Revert "Remove dmenumon variable"
This reverts commit c2b748e793.

Revert back this change. It seems to not be an edge-case anymore since
multiple users have asked about this new behaviour now.
2022-10-28 16:37:56 +02:00
David JULIEN 1b6b09b50d feat: make pinentry window a floating window 2022-10-25 11:56:37 +02:00
Hiltjo Posthuma 50ad171eea bump version to 6.4 2022-10-04 19:35:13 +02:00
Hiltjo Posthuma 970f376973 remove workaround for a crash with color emojis on some systems, now fixed in libXft 2.3.5
2022-09-17 15:32:41 +02:00
Stein c2b748e793 Remove dmenumon variable
Reasoning: Since 2011 dmenu has been capable of working out which
monitor currently has focus in a Xinerama setup, making the use
of the -m flag more or less redundant.

This is easily demonstrated by using dmenu in any other window

There used to be a nodmenu patch that provided these changes:

but this was removed on the basis that it was very easy to work
out and apply manually if needed.

The proposal here is to remove this dependency from dwm. The
mechanism of the dmenumon variable could be provided via a patch
if need be.

The edge case scenario that dmenu does not handle on its own, and
the effect of removing this mechanism, is that if the user trigger
focusmon via keybindings to change focus to another monitor that
has no clients, then dmenu will open on the monitor containing the
window with input focus (or the monitor with the mouse cursor if
no windows have input focus).

If this edge case is important to cover then this can be addressed
by setting input focus to selmon->barwin in the focus function if
there is no client to give focus to (rather than giving focus back
to the root window).
2022-08-28 11:39:43 +02:00
NRK 84d7322113 config.def.h: make keys and buttons const
pretty much all other variables are declared as const when they're not
2022-08-19 11:47:22 +02:00
Stein 5799dd1fca Remove blw variable in favour of calculating the value when needed
The purpose and reasoning behind the bar layout width (blw) variable
in dwm the way it is today may not be immediately obvious.

The use of the variable makes more sense when looking at commit
2ce37bc from 2009 where blw was initialised in the setup function
and it represented the maximum of all available layout symbols.

	for(blw = i = 0; LENGTH(layouts) > 1 && i < LENGTH(layouts); i++) {
		w = TEXTW(layouts[i].symbol);
		blw = MAX(blw, w);

As such the layout symbol back then was fixed in size and both drawbar
and buttonpress depended on this variable.

The the way the blw variable is set today in drawbar means that it
merely caches the size of the layout symbol for the last bar drawn.

While unlikely to happen in practice it is possible that the last bar
drawn is not that of the currently selected monitor, which can result
in misaligned button clicks if there is a difference in layout symbol
width between monitors.
2022-08-17 13:33:57 +02:00
Stein 44adafe006 Make floating windows spawn within the monitor's window area
This is a follow-up on this thread:

The orginal code had constraints such that if a window's starting
attributes (position and size) were to place the window outside of
the edges of the monitor, then the window would be moved into view
at the closest monitor edge.

There was an exception to this where if a top bar is used then the
window should not obscure the bar if present, which meant to place
the window within the window area instead.

The proposed change here makes it the general rule that floating
windows should spawn within the window area rather than within the
monitor area. This makes it simple and consistent with no
exceptions and it makes the intention of the code clear.

This has the benefit of making the behaviour consistent regardless
of whether the user is using a top bar or a bottom bar.

Additionally this will have an effect on patches that modify the
size of the window area. For example if the insets patch is used to
reserve space on the left hand side of the monitor for a dock or a
vertical bar then new floating clients will not obscure that area.
2022-08-12 09:02:34 +02:00
Stein a859676ead Simplify client y-offset correction
The reasoning behind the original line may be lost to time as
it does not make much sense checking the position on the x-axis
to determine how to position the client on the y-axis.

In the context of multi-monitor setups the monitor y position
(m->my) may be greater than 0 (say 500), in which case the window
could be placed out of view if:
   - the window attributes have a 0 value for the y position and
   - we end up using the y position of bh (e.g. 22)

If the aim is to avoid a new floating client covering the bar then
restricting y position to be at least that of the window area
(m->wy) should cover the two cases of using a top bar and using a
bottom bar.
2022-08-10 15:31:21 +02:00
Hiltjo Posthuma e0dee91145 sync code-style patch from libsl 2022-08-08 10:43:09 +02:00
NRK 5e76e7e21d code-style: simplify some checks
main change here is making the `zoom()` logic saner. the rest of the
changes are just small stuff which accumulated on my local branch.

pop() must not be called with NULL. and `zoom()` achieves this, but in a
very (unnecessarily) complicated way:

if c == NULL then nexttiled() will return NULL as well, so we enter this

	if (c == nexttiled(selmon->clients))

in here the !c check fails and the function returns before calling pop()

		if (!c || !(c = nexttiled(c->next)))

however, none of this was needed. we can simply return early if c was NULL.
Also `c` is set to `selmon->sel` so we can use `c` in the first check
instead which makes things shorter.
2022-08-06 16:09:01 +02:00
explosion-mental 5b2e5e7a40 spawn: reduce 2 lines, change fprintf() + perror() + exit() to die("... :")
when calling die and the last character of the string corresponds to
':', die() will call perror(). See util.c

2022-08-02 18:08:51 +02:00
Stein 786f6e2a6f unmanage: stop listening for events for unmanaged windows
This is in particular to avoid flickering in dwm (and high CPU usage)
when hovering the mouse over a tabbed window that was previously
managed by dwm.

Consider the following two scenarios:


We start tabbed (window 0xc000003), tabbed is managed by the
window manager.
We start st being embedded into tabbed.

$ st -w 0xc000003

What happens here is that:
   - tabbed gets a MapRequest for the st window
   - tabbed reparents the st window
   - tabbed will receive X events for the window

The window manager will have no awareness of the st window and the
X server will not send X events to the window manager relating to
the st window.

There is no flickering or any other issues relating to focus.


We start tabbed (window 0xc000003), tabbed is managed by the
window manager.
We start st as normal (window 0xd400005).

What happens here is that:
   - the window manager gets a MapRequest for the st window
   - dwm manages the st window as a normal client
   - dwm will receive X events for the window

Now we use xdotool to trigger a reparenting of the st window into

$ xdotool windowreparent 0xd400005 0xc000003

What happens here is that:
   - tabbed gets a MapRequest for the st window
   - tabbed reparents the st window
   - the window manager gets an UnmapNotify
   - the window manager no longer manages the st window
   - both the window manager and tabbed will receive X events
     for the st window

In dwm move the mouse cursor over the tabbed window.

What happens now is that:
   - dwm will receive a FocusIn event for the tabbed window
   - dwm will set input focus for the tabbed window
   - tabbed will receive a FocusIn event for the main window
   - tabbed will give focus to the window on the currently selected
   - which again triggers a FocusIn event which dwm receives
   - dwm determines that the window that the FocusIn event is for
     (0xd400005) is not the currently selected client (tabbed)
   - dwm sets input focus for the tabbed window
   - this causes an infinite loop as long as the mouse cursor hovers
     the tabbed window, resulting in flickering and high CPU usage

The fix here is to tell the X server that we are no longer interested
in receiving events for this window when the window manager stops
managing the window.
2022-08-02 18:04:56 +02:00
Hiltjo Posthuma e03248a4d5 Revert "do not call signal-unsafe function inside sighanlder"
This reverts commit 6613d9f9a1.

Discussed on the mailinglist:
2022-07-22 09:18:52 +02:00
NRK 6613d9f9a1 do not call signal-unsafe function inside sighanlder
die() calls vprintf, fputc and exit; none of these are
async-signal-safe, see `man 7 signal-safety`.
2022-07-15 20:53:58 +02:00
NRK 9bffa845fa use named parameter for func prototype
all the other prototypes use names.
2022-07-15 20:53:56 +02:00
Hiltjo Posthuma d3f93c7c1a sync latest drw.{c,h} changes from dmenu 2022-05-10 19:07:56 +02:00
Hiltjo Posthuma cd0773cee9 Makefile: add manual path for OpenBSD
Reported by fossy <>, thanks
2022-05-01 18:37:54 +02:00
Chris Down 8b48e30973 manage: Make sure c->isfixed is applied before floating checks
Commit 8806b6e237 ("manage: propertynotify: Reduce cost of unused size
hints") mistakenly removed an early size hints update that's needed to
populate c->isfixed for floating checks at manage() time. This resulted
in fixed (size hint min dimensions == max dimensions) subset of windows
not floating when they should.

See for discussion.
2022-04-26 15:50:55 +02:00
Hiltjo Posthuma a83dc20310 LICENSE: add Chris Down 2022-04-26 15:50:32 +02:00
Hiltjo Posthuma a4771de5ba Revert "manage: For isfloating/oldstate check/set, ensure trans client actually exists"
This reverts commit bece862a0f.

It caused a regression, for example:
2022-04-26 10:30:59 +02:00
David JULIEN 82003c8dad feat: personnal config 2022-04-23 15:58:34 +02:00
David JULIEN a1ab7f5da7 feat: noboarder patch 2022-04-23 15:57:12 +02:00
David JULIEN 3a5835b297 feat: xresources patch 2022-04-23 14:05:27 +02:00
David JULIEN 65e044bd26 feat: center patch 2022-04-23 13:37:21 +02:00
David JULIEN e382777f81 feat: swallow patch 2022-04-23 13:31:45 +02:00
David JULIEN a7ad711b5a feat: notitle patch 2022-04-23 13:30:27 +02:00
David JULIEN a2dd850d3a feat: hide_vacant_tags patch 2022-04-23 13:29:31 +02:00
David JULIEN 116cf1f7c7 feat: fullgaps patch 2022-04-23 13:28:58 +02:00
David JULIEN 1d38ae649f feat: attachaside patch 2022-04-23 13:27:36 +02:00
David JULIEN c4f556bce0
start fresh for 6.3 2022-04-23 13:10:37 +02:00
Santtu Lakkala d93ff48803 Update monitor positions also on removal
When monitors are removed, the coordinates of existing monitors may
change, if the removed monitors had smaller coordinates than the
remaining ones.

Remove special case handling so that the same update-if-necessary loop
is run also in the case when monitors are removed.
2022-04-16 16:59:03 +02:00
Chris Down 8806b6e237 manage: propertynotify: Reduce cost of unused size hints
This patch defers all size hint calculations until they are actually
needed, drastically reducing the number of calls to updatesizehints(),
which can be expensive when called repeatedly (as it currently is during

In my unscientific testing this reduces calls to updatesizehints() by
over 90% during a typical work session. There are no functional changes
for users other than an increase in responsiveness after resizes and
a reduction in CPU time.

In slower environments or X servers, this patch also offers an
improvement in responsiveness that is often tangible after resizing a
client that changes hints during resizes.

There are two main motivations to defer this work to the time of hint

1. Some clients, especially terminals using incremental size hints,
   resend XA_WM_NORMAL_HINTS events on resize to avoid fighting with the
   WM or mouse resizing. For example, some terminals like urxvt clear
   PBaseSize and PResizeInc during XResizeWindow and restore them

   For this reason, after the resize is concluded, we typically receive
   a backlogged XA_WM_NORMAL_HINTS message for each update period with
   movement, which is useless. In some cases one may get hundreds or
   thousands of XA_WM_NORMAL_HINTS messages on large resizes, and
   currently all of these result in a separate updatesizehints() call,
   of which all but the final one are immediately outdated.

   (We can't just blindly discard these messages during resizes like we
   do for EnterNotify, because some of them might actually be for other
   windows, and may not be XA_WM_NORMAL_HINTS events.)

2. For users which use resizehints=0 most of these updates are unused
   anyway -- in the normal case where the client is not floating these
   values won't be used, so there's no need to calculate them up front.

A synthetic test using the mouse to resize a floating terminal window
from roughly 256x256 to 1024x1024 and back again shows that the number
of calls to updatesizehints() goes from over 500 before this patch (one
for each update interval with movement) to 2 after this patch (one for
each hint application), with no change in user visible behaviour.

This also reduces the delay before dwm is ready to process new events
again after a large resize on such a client, as it avoids the thundering
herd of updatesizehints() calls when hundreds of backlogged
XA_WM_NORMAL_HINTS messages appear at once after a resize is finished.
2022-04-16 16:37:46 +02:00
Miles Alan bece862a0f manage: For isfloating/oldstate check/set, ensure trans client actually exists
In certain instances trans may be set to a window that doesn't actually
map to a client via wintoclient; in this case it doesn't make sense
to set isfloating/oldstate since trans is essentially invalid in that
case / correlates to the above condition check where trans is set /
XGetTransientForHint is called.
2022-03-13 17:32:56 +01:00
NRK 60e9a14998 fix mem leak in cleanup()
maybe leak isn't the best word, given that the object lives for the
entire duration of the program's lifetime.

however, all elements of scheme are free-ed, can't think of any reason
why scheme itself should be an exception.
2022-03-13 10:49:43 +01:00
Hiltjo Posthuma d39e2f3441 bump version to 6.3 2022-01-07 12:39:18 +01:00
Chris Down 8657affa2a 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

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().
2021-12-19 16:16:30 +01:00
Hiltjo Posthuma a786211d6c Revert "Improve speed of drw_text when provided with large strings"
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.
2021-08-20 23:09:48 +02:00
Miles Alan 716233534b 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.
2021-08-09 18:25:19 +02:00
Quentin Rameau 138b405f0c Add a configuration option for fullscreen locking
Some people are annoyed to have this new behaviour forced for some
application which use fake fullscreen.
2021-07-14 11:26:37 +02:00
Chris Down 67d76bdc68 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.

2021-03-29 19:16:27 +02:00