aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* add terminess fontsinanmohd2023-01-111-1/+1
|
* remove gimp floating rulesinanmohd2023-01-111-1/+2
|
* support for media control keyssinanmohd2023-01-111-4/+12
|
* key bindings, added mic mute swicthsinanmohd2023-01-111-3/+5
|
* add keysym values for undefined keyssinanmohd2023-01-111-0/+13
|
* change font sizesinanmohd2023-01-111-2/+4
|
* emoji supportsinanmohd2023-01-111-0/+1
|
* make nnn use the terminal color schemesinanmohd2023-01-111-1/+1
|
* added center patchsinanmohd2023-01-113-7/+18
|
* added titlecolor patchsinanmohd2023-01-113-5/+7
|
* added xrdb patch for pywalsinanmohd2023-01-115-12/+77
|
* change border pixel of windows from 1 to 2sinanmohd2023-01-111-1/+1
|
* added swallow patchsinanmohd2023-01-114-10/+238
|
* added 14 keybindings for audio control, ncmpcpp, nnn, surf-tabbed, ↵sinanmohd2023-01-111-2/+32
| | | | librewolf, ytfzf, screenlock, screenshot, bluetooth, dmsounds
* changed fonts to product sanssinanmohd2023-01-111-2/+2
|
* added fullgaps patchsinanmohd2023-01-114-10/+41
|
* added README.md filesinanmohd2023-01-111-0/+3
|
* made metakey the modkeysinanmohd2023-01-111-1/+1
|
* grabkeys: Avoid missing events when a keysym maps to multiple keycodesChris Down2022-12-071-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Remove dmenumon variable"Hiltjo Posthuma2022-10-282-1/+4
| | | | | | | 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.
* bump version to 6.4Hiltjo Posthuma2022-10-041-1/+1
|
* remove workaround for a crash with color emojis on some systems, now fixed ↵Hiltjo Posthuma2022-09-171-14/+0
| | | | | | in libXft 2.3.5 https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/libXft-2.3.5/NEWS
* Remove dmenumon variableStein2022-08-282-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* config.def.h: make keys and buttons constNRK2022-08-191-2/+2
| | | | | pretty much all other variables are declared as const when they're not modified.
* Remove blw variable in favour of calculating the value when neededStein2022-08-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Make floating windows spawn within the monitor's window areaStein2022-08-121-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Simplify client y-offset correctionStein2022-08-101-3/+1
| | | | | | | | | | | | | | | | | 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.
* sync code-style patch from libslHiltjo Posthuma2022-08-081-11/+12
|
* code-style: simplify some checksNRK2022-08-061-15/+8
| | | | | | | | | | | | | | | | | | | | | | 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.
* spawn: reduce 2 lines, change fprintf() + perror() + exit() to die("... :")explosion-mental2022-08-021-3/+1
| | | | | | | 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
* unmanage: stop listening for events for unmanaged windowsStein2022-08-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Revert "do not call signal-unsafe function inside sighanlder"Hiltjo Posthuma2022-07-221-2/+2
| | | | | | | This reverts commit 6613d9f9a1a5630bab30bc2b70bdc793977073ee. Discussed on the mailinglist: https://lists.suckless.org/hackers/2207/18405.html
* do not call signal-unsafe function inside sighanlderNRK2022-07-151-2/+2
| | | | | die() calls vprintf, fputc and exit; none of these are async-signal-safe, see `man 7 signal-safety`.
* use named parameter for func prototypeNRK2022-07-151-2/+2
| | | | all the other prototypes use names.
* sync latest drw.{c,h} changes from dmenuHiltjo Posthuma2022-05-102-30/+59
|
* Makefile: add manual path for OpenBSDHiltjo Posthuma2022-05-011-0/+1
| | | | Reported by fossy <fossy@dnmx.org>, thanks
* manage: Make sure c->isfixed is applied before floating checksChris Down2022-04-261-0/+1
| | | | | | | | | | 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.
* LICENSE: add Chris DownHiltjo Posthuma2022-04-261-0/+1
|
* Revert "manage: For isfloating/oldstate check/set, ensure trans client ↵Hiltjo Posthuma2022-04-261-1/+1
| | | | | | | | | actually exists" This reverts commit bece862a0fc4fc18ef9065b18cd28e2032d0d975. It caused a regression, for example: https://lists.suckless.org/hackers/2203/18220.html
* Update monitor positions also on removalSanttu Lakkala2022-04-161-34/+34
| | | | | | | | | 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.
* manage: propertynotify: Reduce cost of unused size hintsChris Down2022-04-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* manage: For isfloating/oldstate check/set, ensure trans client actually existsMiles Alan2022-03-131-1/+1
| | | | | | | | 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.
* fix mem leak in cleanup()NRK2022-03-131-0/+1
| | | | | | | | 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.
* bump version to 6.3Hiltjo Posthuma2022-01-071-1/+1
|
* drawbar: Don't expend effort drawing bar if it is occludedChris Down2021-12-191-0/+3
| | | | | | | | | | | | | | | | | 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().
* Revert "Improve speed of drw_text when provided with large strings"Hiltjo Posthuma2021-08-201-5/+2
| | | | | | | This reverts commit 716233534b35f74dba5a46ade8f1a6f8cc72fea4. It causes issues with truncation of characters when the text does not fit and so on. The patch should be reworked and properly tested.
* Improve speed of drw_text when provided with large stringsMiles Alan2021-08-091-2/+5
| | | | | | 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.
* Add a configuration option for fullscreen lockingQuentin Rameau2021-07-142-1/+2
| | | | | Some people are annoyed to have this new behaviour forced for some application which use fake fullscreen.
* Do not allow focus to drift from fullscreen client via focusstack()Chris Down2021-03-291-1/+1
| | | | | | | | | | | | | 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/
* Fix x coordinate calculation in buttonpress.Ian Remmler2020-08-211-1/+1
|