| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch adds "window swallowing" to dwm as known from Plan 9's
windowing system rio.
Clients marked with isterminal in config.h swallow a window opened by
any child process, e.g. running xclock in a terminal. Closing the xclock
window restores the terminal window in the current position.
This patch helps users spawning a lot of graphical programs from their
command line by avoiding cluttering the screen with many unusable
terminals. Being deep down in a directory hierarchy just does not make
the use of dmenu feasible.
Dependencies
* libxcb
* Xlib-libxcb
* xcb-res
These dependencies are needed due to the use of the latest revision of
the X Resource Extension which is unsupported in vanilla Xlib.
Notes:
* The window swallowing functionality requires dwm to walk the process
tree, which is an inherently OS-specific task. Only Linux and FreeBSD
are supported at this time. Please contact one of the authors if you
would like to help expand the list of supported operating systems.
* Only terminals created by local processes can swallow windows, and
only windows created by local processes can be swallowed.
|
|
Only allow clients to "fullscreen" into space currently given to them.
As an example, this will allow you to view a fullscreen video in your
browser on one half of the screen, while having the other half available
for other tasks.
|
|
This patch enables the use of multiple pre-assigned scratchpad
terminals. This patch uses reserved tags for stowing scratchpads, these
are the tagmasks just beyond those defined for normal use.
DWM's rule system is used to handle spawning scratchpad windows. We use
one rule per scratchpad to define what SPTAG it belongs to, whether it
is floating, an instance identifier, and what program to exec in st
(your shell by default). Keybinds should be setup to call togglescratch
with a pointer to the rule struct which defines the scratchpad.
The togglescratch function uses the information in the rule to craft an
st command line to spawn. However, if some client is already open on
the rule's tagmask, it will just act like toggleview(tagmask).
Normal clients may be opened while viewing scratchpads, they are always
excluded from scratchpad tags.
This patch is inspired by the "scratchpad" and "scratchpads" patches
from suckless.org.
|
|
Resets the layout and mfact if there is only one client visible.
This applies cleanly to vanilla dwm, but is mostly only useful alongside
the pertag patch, since otherwise all layouts and mfacts will be reset.
You can also set a binding to trigger this on demand, see the new call
to resetlayout in config.def.h.
This patch also resets nmaster to its default value as well.
|
|
pushup and pushdown provide a way to move clients inside the clients
list.
|
|
More general approach to taglayouts patch. This patch keeps layout,
mwfact, and nmaster per tag.
This is the 'same barpos' version of the patch, which keeps the bar
position and visibility global / constant across all tags.
|
|
Layout adapted from centerfloatingmaster to simply tile all clients
horizontally across the screen, without respect to mfact or nmaster.
|
|
This patch adds an extra layout mode to dwm called grid in which the
windows are arranged in a grid of equal sizes. It comes in very handy,
especially with tools that operate on multiple windows at once; e.g.
Cluster SSH.
The patch would look a lot uglier without Jukka Salmi's constant help.
Thanks Jukka :-)
|
|
elit is an inversion of the default tiling layout with the following
characteristics:
- master area is on the right
- master windows are taken from the bottom of the stack (nmaster of
them)
- new clients spawn on the top of the stack and therefore appear at
the top of the slave stacking area on the left
- mfact controls the middle division point (motion is consistent
with default layout)
In effect, elit will keep specific client windows pinned in place on the
right, allowing the use of a dynamic stack on the left. I've found this
useful to use on a secondary monitor for opening and closing short-lived
terminals without affecting the geometry of a web browser window, which
can reserve the full height of the display.
|
|
This patch adds an extra layout to dwm called col in which the windows
in the master area are arranged in colums of equal size. The number of
columns is always nmaster + 1, and the last column is a stack of
leftover windows just like the normal tile layout. It effectively acts
like the default tiling mode, except provides for vertical instead of
horizontal master windows.
|
|
centeredmaster centers the nmaster area on screen, using mfact * monitor
width & height, with the stacked windows distributed to the left and
right. It can be selected with [Alt]+[u].
With one and two clients in master respectively this results in:
+------------------------------+ +------------------------------+
|+--------++--------++--------+| |+--------++--------++--------+|
|| || || || || || || ||
|| || || || || || M1 || ||
|| || || || || || || ||
|| S2 || M || S1 || || |+--------+| ||
|| || || || || |+--------+| ||
|| || || || || || || ||
|| || || || || || M2 || ||
|| || || || || || || ||
|+--------++--------++--------+| |+--------++--------++--------+|
+------------------------------+ +------------------------------+
This layout can be useful on large screens, where monocle or htile might
be either too large or forcing the user to type in a corner of the
screen. It allows for instance to center the editor while being able to
keep an eye on background processes (logs, tests, ...).
|
|
dwm's built-in status bar is now only shown when HOLDKEY is pressed. In
addition the bar will now overlay the display. This will work
regardless of the topbar setting. This is meant to be used with the bar
off by default.
None of the togglebar code has been removed, although you might want to
remove the togglebar binding in your config.def.h. The holdbar-modkey
patch (this) is a variant where holdbar is only active when the bar is
toggled off and the holdkey can be the same as the modkey.
This reverts commit 8657affa2a61 ("drawbar: Don't expend effort drawing
bar if it is occluded"). When holdbar is applied, its effect prevents
the bar from ever being drawn. Only a black rectangle appears when the
key is held.
This patch allows HOLDKEY to also be used in place of MODKEY for sending
keystrokes to dwm while simultaneously peeking at the statusbar.
|
|
This is an overhaul of the statusbar appearance, inspired by a
combination of the patches: rearrangebar, taglabels, hide-vacant-tags,
and statusallmons.
The bar layout (from left to right) is now just tag labels, status, and
the layout symbol. However, tag labels are generally larger than usual
and contain the name of the leading client on each tag. The format of
these new labels is controlled by a new option in config.h.
The layout symbol is moved all the way to the far right, per
rearrangebar, however the center area is left clear for the tag labels
to grow into.
statusallmons and hide-vacant-tags work exactly as normal, but are
implemented from scratch in this patch to avoid conflicts.
This patch addresses some oversights by the others in the buttonpress()
function for handling clicks on the statusbar. The logic is updated to
correctly handle the new location of the status and ltsymbol. Tag
labels are stored in the Monitor struct (instead of the original patch's
global variable) so tag clicks can be handled correctly on multimonitor.
This patch is updated to identify any hidden clients opened by the
scratchpadz patch.
|
|
Allow dwm to have translucent bars, while keeping all the text on it
opaque, just like the alpha-patch for st.
Fix transparent borders
-----------------------
By default dwm might make windows' borders transparent when using
composit window manager (e.g. xcompmgr, picom). Alpha patch allows to
make borders opaque.
If all you want is to make borders opaque, you don't care about
statusbar opacity and/or have problems applying alpha patch, then you
might use fixborders patch instead.
|
|
From sigaction(2):
A child created via fork(2) inherits a copy of its parent's signal dispositions.
During an execve(2), the dispositions of handled signals are reset to the default;
the dispositions of ignored signals are left unchanged.
This refused to start directly some programs from configuring in config.h:
static Key keys[] = {
MODKEY, XK_o, spawn, {.v = cmd } },
};
Some reported programs that didn't start were: mpv, anki, dmenu_extended.
Reported by pfx.
Initial patch suggestion by Storkman.
|
|
signal() semantics are pretty unclearly specified. For example, depending on OS
kernel and libc, the handler may be returned to SIG_DFL (hence the inner call
to read the signal handler). Moving to sigaction() means the behaviour is
consistently defined.
Using SA_NOCLDWAIT also allows us to avoid calling the non-reentrant function
die() in the handler.
Some addditional notes for archival purposes:
* NRK pointed out errno of waitpid could also theoretically get clobbered.
* The original patch was iterated on and modified by NRK and Hiltjo:
* SIG_DFL was changed to SIG_IGN, this is required, atleast on older systems
such as tested on Slackware 11.
* signals are not blocked using sigprocmask, because in theory it would
briefly for example also ignore a SIGTERM signal. It is OK if waitpid() is (in
theory interrupted).
POSIX reference:
"Consequences of Process Termination":
https://pubs.opengroup.org/onlinepubs/9699919799/functions/_Exit.html#tag_16_01_03_01
|
|
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
XF86AudioPlay:
% 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.
0: https://github.com/cdown/dwm/issues/11
|
|
This reverts commit c2b748e7931e5f28984efc236f9b1a212dbc65e8.
Revert back this change. It seems to not be an edge-case anymore since
multiple users have asked about this new behaviour now.
|
|
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
manager.
There used to be a nodmenu patch that provided these changes:
https://git.suckless.org/sites/commit/ed68e3629de4ef2ca2d3f8893a79fb570b4c0cbc.html
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).
|
|
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.
|
|
This is a follow-up on this thread:
https://lists.suckless.org/hackers/2208/18462.html
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.
|
|
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.
|
|
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
branch:
if (c == nexttiled(selmon->clients))
in here the !c check fails and the function returns before calling pop()
if (!c || !(c = nexttiled(c->next)))
return;
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.
|
|
when calling die and the last character of the string corresponds to
':', die() will call perror(). See util.c
Also change EXIT_SUCCESS to EXIT_FAILURE
|
|
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:
1)
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.
2)
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
tabbed.
$ 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
tab
- 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.
|
|
This reverts commit 6613d9f9a1a5630bab30bc2b70bdc793977073ee.
Discussed on the mailinglist:
https://lists.suckless.org/hackers/2207/18405.html
|
|
die() calls vprintf, fputc and exit; none of these are
async-signal-safe, see `man 7 signal-safety`.
|
|
all the other prototypes use names.
|
|
Commit 8806b6e23793 ("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 https://lists.suckless.org/dev/2204/34730.html for discussion.
|
|
actually exists"
This reverts commit bece862a0fc4fc18ef9065b18cd28e2032d0d975.
It caused a regression, for example:
https://lists.suckless.org/hackers/2203/18220.html
|
|
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.
|
|
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
resizes).
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
application:
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
afterwards.
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.
|
|
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.
|
|
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.
|
|
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().
|
|
Some people are annoyed to have this new behaviour forced for some
application which use fake fullscreen.
|
|
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.
|
|
No functional changes, but for every other function we have a forward
declaration here. getatomprop should be no exception.
|
|
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.
|
|
|
|
|
