bakkeby / patches Goto Github PK

Hello!
First of all thank so much for this awesome collection of dwm patches and fixes to existing patches. I was going nuts about the issues the "official" systray and alpha patches caused together but your alpha-systray patch helped greatly.

I am running into a bit of an issue tho when also integrating both patches together with the barpadding patch.

On my primary monitor all patches work together without issues and everything looks as it should.

Primary Monitor upper left corner:

Primary Monitor lower left corner:

But if I move a window or open one on one of my secondary displays the spacing is off.

Secondary Monitor upper left corner:

Secondary Monitor lower left corner:

It looks like the window is "pushed upwards" so I assume there is somewhere an issue with subtracting the correct amount of spacing. Without the barpadding patch the spacing around the windows is correct on all monitors.
When I toggle the bar off and on again (via shortcut mod+b) the window fits correctly again on the secondary display. Which in my eyes means that the togglebar function works correctly when it comes to calling XMoveResizeWindow.
So I assume the issue is somewhere when first drawing the window on a screen or during the setup of the secondary screens.

I've tinkered around a little to see if I find the piece of code that is responsible for the initial setup of windows on a secondary screen but I'm not too familiar with the functions X11 provides. I looked at some of the functions the barpadding patch changes to see it I could spot anything that might have gone wrong but couldn't really find anything.
So I thought I'd ask here in hope you have an idea what might be the issue. If needed I can also link my suckless/dwm repo which i currently only have on gitlab.

I'm very sorry if this is the wrong place to ask this but I though you might have an idea on how do fix my issue.

Thank you so much in advance and I hope you'll have a lovely Sunday!

I am using the systray patch alongside statuscmd and status2d. I managed to get them working together after some trouble but now another patch, status bar on all monitors is causing some trouble. Basically, as intended, the status bar is being displayed with the length of the systray in mind, therefore preventing overlap with applet icons and so on:

The problem however starts once I try to display this on both my monitors. My second monitor, although also displaying the status bar as per the status bar on all monitors patch, does not display the systray but still takes into account the systray's "offset", resulting in the following strange look:

I pinned the systray to this other monitor and it then displayed correctly, but obviously the old monitor (now without the systray) was now the one with this weird bug.

Would it be possible to pin the systray to both screens in order to get around this weird problem?

So after I implemented your patch I had the idea to have the mouse left button execute placemouse if tiled and movemouse if floating. It feels more natural to me and you can still float a window with the mouse via the middle button. The (simple) code is as follows:

void
moveorplace(const Arg *arg) {
    if (ISFLOATING)
        movemouse(arg);
    else
        placemouse(arg);
}

with

#define ISFLOATING              (!selmon->lt[selmon->sellt]->arrange || selmon->sel->isfloating)

Also I think I found a bug: When dropping the window into the master area for example and then move the mouse to focus another window it receives focus, but the borders don't take the focused color. You can easily mitigate this by always calling focus(c) instead of only calling it if the monitor has changed. Like this:

		arrangemon(c->mon);
		c->mon = m;
		attach(c);
		attachstack(c);
		selmon = m;
	}

        focus(c);
	c->beingmoved = 0;

While trying to edit some stuff I found myself not knowing what 2 or 3 meant. I think it's best to use enum instead; The names can probably be improved, but this is certainly better than what we currently have, magic numbers.

enum { FFSNone, FFSActive, FFSActual, FFSActualExit }; /* fakefullscreen */

I'd supply the fix myself, but I see that the patch has evolved a bit more compared to what I have on my build. Unfortunately the changes don't look interesting enough for me to bother porting them. Here's a diff on my build if you're interested: https://dpaste.com/82NLG5QT6

When the patch is applied, the bar will flicker sometimes when focus is changed rapidly, either by calling focusstack() or moving with the mouse. Seems to happen more frequently if there is something in the status area. It does not occur when using the dwm-alpha-6.2 patch on it's own, or with dwm-systray-6.2 by itself either.

Running a compositor such as picom or xcompmgr seems to have no effect, as it does the same thing.

dwm-vanitygaps-6.2.diff has pertag and cfacts references and other as well, I think you overlooked it when you updated the .diff file :)

When no systray apps are active:

With any systray app: e.g nm-applet

Adding more systray apps pushes dwmblocks further under bartab

Similar behaviour is observed when statuscmd patch is added with systray (no bartabs)

Any workaround for this for statuscmd and bartabgroups ? Something like this
OR is the issue with systray not updating the width properly ?

Very minor discrepancy in the pertag-monitorrules patch you have in config.def.h - the comments for the default and secondary displays appear to be swapped.

The top line suggests suggests a secondary display, when in my case setting these rules applies to the primary. I haven't ruled out the fact that I am setting my primary display via the Nvidia driver on my end, however.

Again, nothing major, but for the sake of consistency I just wanted to point that out.

Hi, I patched netactiverules manually and there wasn't any error during compilation but I can't get it to work.
I want this patch to stop focusing brave but no matter what focusonnetactive works the same

I added this patch to dwm flexipatch build if it makes any difference

Hi, after applying dwm-focusedontop patch, i found misbehavior when using it with monocle layout as default layout, it seem that the clients switching focus continously until swithced to another layout or try to click outside window area, here the preview

I'm new to DWM, when I try to apply some patches and merge them on clean master branch I often get conflicting between those patches. So how do you get over this issue?

This patch seems to be broken now with the latest commits to dwm on the suckless git. I tried to fix it by reading the few commits the past few weeks and editing your patch but I can't seem to get it to work.

Also I didnt know if you wanted to take a look at this guys systray patch to see if implementing it along with the alpha patch would be a better fit:
https://www.reddit.com/r/suckless/comments/ezcemb/dwm_how_to_make_a_standalone_tray_app_always/

patch here: https://github.com/szatanjl/dwm/commit/f40d492ff9eedfcea6136c3d53155780b09b995a.patch

I tried for about 3 days to manually get a good systray and alpha patch going. Frankly my only goal was to get OPAQUE borders on windows since the compositor (picom) likes to make these transparent too and the alpha patch prevents this by using ARGB values for the border.

I found another bug with multiple monitor setups. This time with rioresize - its much easier to resolve. It was just missing an arrange() on the old monitor:

diff --git a/moonwm.c b/moonwm.c
index ff18d60..f64b41f 100644
--- a/moonwm.c
+++ b/moonwm.c
@@ -2441,7 +2441,8 @@ riodraw(Client *c, const char slopstyle[])
 void
 rioposition(Client *c, int x, int y, int w, int h)
 {
-	Monitor *m;
+	Monitor *m, *mold;
+    mold = c->mon;
 	if ((m = recttomon(x, y, w, h)) && m != c->mon) {
 		detach(c);
 		detachstack(c);
@@ -2458,7 +2459,9 @@ rioposition(Client *c, int x, int y, int w, int h)
 		resize(c, x, y, w - (borderpx * 2), h - (borderpx * 2), borderpx, 0);
 	else
 		resize(c, x - borderpx, y - borderpx, w, h, borderpx, 0);
+	drawbar(mold);
 	drawbar(c->mon);
+	arrange(mold);
 	arrange(c->mon);
 
 	riodimensions[3] = -1;

hi if you dont mind,i want to be able to toggle systray . this what i've done so far.

void
togglesystray()
{
	if (showsystray)
		XUnmapWindow(dpy, systray->win);
	showsystray = !showsystray;
	drawbarwin(systray->bar);
} 

I patched my dwm with pertag patch and then I tried to apply your monitorrules patch, I am getting a error when make, monrules undeclared, I don't know what is causing it, there is monrules patched successfully to config.def.h and also it gives error about pertag has no member prevzooms.

Full error

dwm.c:849:28: error: ‘monrules’ undeclared (first use in this function); did you mean ‘rules’?
  849 |     for (j = 0; j < LENGTH(monrules); j++) {
      |                            ^~~~~~~~
dwm.c:54:41: note: in definition of macro ‘LENGTH’
   54 | #define LENGTH(X)               (sizeof X / sizeof X[0])
      |                                         ^
dwm.c:849:28: note: each undeclared identifier is reported only once for each function it appears in
  849 |     for (j = 0; j < LENGTH(monrules); j++) {
      |                            ^~~~~~~~
dwm.c:54:41: note: in definition of macro ‘LENGTH’
   54 | #define LENGTH(X)               (sizeof X / sizeof X[0])
      |                                         ^
dwm.c:881:18: error: ‘Pertag’ has no member named ‘prevzooms’
  881 |         m->pertag->prevzooms[i] = NULL;
      |                  ^~
make: *** [Makefile:18: dwm.o] Error 1

My dwm.c

Monitor *
createmon(void)
{
    Monitor *m, *mon;
    int i, mi, j, layout;
    const MonitorRule *mr;

	m = ecalloc(1, sizeof(Monitor));
	m->tagset[0] = m->tagset[1] = 1;
	m->mfact = mfact;
	m->nmaster = nmaster;
	m->showbar = showbar;
	m->topbar = topbar;
	m->gappih = gappih;
	m->gappiv = gappiv;
	m->gappoh = gappoh;
	m->gappov = gappov;

    for (mi = 0, mon = mons; mon; mon = mon->next, mi++);
    for (j = 0; j < LENGTH(monrules); j++) {
        mr = &monrules[j];
        if ((mr->monitor == -1 || mr->monitor == mi)
                && (mr->tag <= 0 || (m->tagset[0] & (1 << (mr->tag - 1))))
        ) {
            layout = MAX(mr->layout, 0);
            layout = MIN(layout, LENGTH(layouts) - 1);
            m->lt[0] = &layouts[layout];
            m->lt[1] = &layouts[1 % LENGTH(layouts)];
            strncpy(m->ltsymbol, layouts[layout].symbol, sizeof m->ltsymbol);
 
            if (mr->mfact > -1)
               m->mfact = mr->mfact;
            if (mr->nmaster > -1)
                m->nmaster = mr->nmaster;
            if (mr->showbar > -1)
               m->showbar = mr->showbar;
            if (mr->topbar > -1)
               m->topbar = mr->topbar;
            break;
        }
    }

    if (!(m->pertag = (Pertag *)calloc(1, sizeof(Pertag))))
        die("fatal: could not malloc() %u bytes\n", sizeof(Pertag));
    m->pertag->curtag = m->pertag->prevtag = 1;

    for (i = 0; i <= LENGTH(tags); i++) {
        /* init layouts */
        m->pertag->sellts[i] = m->sellt;
  
        /* swap focus and zoomswap*/
        m->pertag->prevzooms[i] = NULL;
  
        for (j = 0; j < LENGTH(monrules); j++) {
            mr = &monrules[j];
            if ((mr->monitor == -1 || mr->monitor == mi) && (mr->tag == -1 || mr->tag == i)) {
                layout = MAX(mr->layout, 0);
                layout = MIN(layout, LENGTH(layouts) - 1);
                m->pertag->ltidxs[i][0] = &layouts[layout];
                m->pertag->ltidxs[i][1] = m->lt[0];
                m->pertag->nmasters[i] = (mr->nmaster > -1 ? mr->nmaster : m->nmaster);
                m->pertag->mfacts[i] = (mr->mfact > -1 ? mr->mfact : m->mfact);
                m->pertag->showbars[i] = (mr->showbar > -1 ? mr->showbar : m->showbar);
                break;
            }
        }
    }

	return m;
}

is it currently possible to add monitor specific cfacts like how there is an mfact value in monitorrules?

As the title says, I want to change the color scheme for the status bar to make different foreground and background color.
I tried to do it myself but still no luck.
A solution like colorbar patch will be really great!
Help me!

Firstly thank you for your patches.

This seems to be a known issue, where you start an app in fullscreen mode, it works properly until you switch to another tag and back to the app, then it will be stuck (sound and commands still works, but the screen will be black).

This isn't an issue with your patches, but since you seem to know a lot about the dwm project I thought about asking you if you know something about an workaround, patch, or anything else.

This user on reddit said it solved it's issue with the fullscreen patch.

I tried the fullscreen patch (now I'm using dwm-fullscreen-compilation-6.2.diff) but still experiencing the problem.

both vanitygaps patches use

• { "H[]", deck },
  as a deck layout indicator, while flexipatch and the official deck patch use [D] ... I'm assuming this is a mistake? the H[] solution looks kinda weird when used

Hello there,

I just patched my dwm build with fullscreen compilation and also use the noborder patch.

When a window is in a tiled mode (fakescreen toggle off) and when I switch to monocle mode, the borders vanish as expected. However the main issue is when fakefullscreen is toggled on when in tiling mode and then I switch over to monocle mode. The borders in this case remain visible. But if I enter monocle mode with fakefullscreen toggle off and then I turn it on, the borders vanish. Is this a known bug that is addressed in #9?. I got lost with the technicality and hence am asking this issue. Pardon me if it's already addressed.

Thanks in advance!

Hi! I have a question about the flextile layout. Flextile introduces the idea of a second stack, so I can put a "deck" layout on two stacks, that's awesome. Now there's this patch called inplacerotate instead of move the focus, the entire stack rotates, it's useful with the deck layout to not send windows to master. With two stacks though behaves weird (well, as expected) because if I rotate one stack the second stack rotates too, making a two stacks deck useless. There's a way to change the inplacerotate patch to respect my second stack?

On a second question of the flextile layout, there's a way to activate a specific split for stack/master without paas through every layout? For example to change the stack from vertical split to gapless grid. I know I can write a new layout and that's what I've done, but it'll be more flexible to toggle the desired split when I want. Thanks!!!

When enabling both patches, the pointer warps to the center of the client right after the click, messing the drag.
Is there any way on restack method to avoid the warp call until the button press release?

FYI, the changes made to the prevtiled() function in the winttileactions patch appear to slightly break the behavior of zoomswap, probably due to this statement being absent in wintitleactions:

+	if (!c || c == c->mon->clients)
+		return NULL;

Without this, zoomswap seems to get confused when you move a client to a new tag. Calling zoom just places the newly moved client back on the last tag. I'm not sure how consistent this bug is, I only briefly tested it, but adding the above statement back in appears to solve it.

Hi!

I'm using the togglegaps() function from vanitygaps.c but this works for all tags. Is there a way to only toggle gaps for the currently active tag, just like how the pertag patch works.

I've tried removing the relevant lines from the function but I get a compilation error.

void
togglegaps(const Arg *arg)
{
	#if PERTAG_PATCH  // <-- removed this
	selmon->pertag->enablegaps[selmon->pertag->curtag] = !selmon->pertag->enablegaps[selmon->pertag->curtag];
	#else  // <-- removed this
	enablegaps = !enablegaps;  // <-- removed this
	#endif // PERTAG_PATCH  // <-- removed this
	arrange(NULL);
}

Thanks!

Tested with both dwm-6.2 and the latest git commit. When applying the swallowing patch from this repository, opening up a floating terminal configured as one in config.def.h, and repeatedly launching a window that swallows the terminal, when the swallowing window is killed the terminal will have decreased in size by a few pixels. I believe this to be related to the resizing logic and border sizes somehow, but I am not clear on how. The code makes sense to me the way it is. I can take a screencast if needed.

I am trying to merge the attachasidebelow patch and riospawn + rioswallow, but am running into an issue with riospawn. In order to merge both attachasidebelow and the rio code I had to change one line in manage, that being this (ignore the config.def.h changes). With this change everything now works when it comes to attachasidebelow and rioresize, but now for some reason riospawn no longer works. I am unsure if this change broke something related to it as it was working before. I did look over the codebase for riospawn in my dwm.c, but could not find any issues. Do you know if this is a byproduct of the support for attachasidebelow? Sorry if this is a dumb question ;-;

Update

Ignore me, seems control key is not sending to my VM and that was the issue. Gonna close this, but not delete it so people can see the diff to add attachasidebelow support.

Sadly I'm not skilled enough to handle it myself.

dwm.c: In function ‘setup’:
dwm.c:1600:46: error: ‘alphas’ undeclared (first use in this function)
 1600 |   scheme[i] = drw_scm_create(drw, colors[i], alphas[i], 3);
      |                                              ^~~~~~
dwm.c:1600:46: note: each undeclared identifier is reported only once for each function it appears in
At top level:

I think the cfacts-vanitygaps patch is broken .. it doesn't implement the cfacts function at all, or is this supposed to be applied on top of cfacts?

When I tried to apply the patch dwm-cfacts-vanitygaps-6.2.diff with git am -3 it said

error: sha1 information is lacking or useless (dwm.c).
error: could not build the fake ancestor

That is indeed true, the repo doesn't have any objects with the sha1 hashes(checked with git show):

index 5592c57..7d503cb 100644

Please update the patch with the correct hashes so that users can use 3-way merge for patching.

Hi, I have recently fixed some memory leaks and thought I might share. I have not checked whether they still exist in the current patches, but I am pretty sure they do. I linked to the commits in my build, so the fixes might not be exactly where they are in vanilla dwm, but it should be pretty straight forward, when looking at the patches. The fixes are all pretty simple.

dwm-systray-6.2.diff (don't let the wrong commit message fool you)

dwm-riodraw-6.2.diff/dwm-riodraw-nopidmatching-6.2.diff

dwm-pertag-6.2.diff

dwm itself (I will try to submit this upstream)

I also found a bug in focusonnetactive, that doesn't remove the borders on the previous client, if the newly focused client is on another monitor.
dwm-focusonnetactive-6.2.diff

I have also found this memory leak in the xrdb patch but it is not part of the collection. Maybe it helps anyway. There is also another memory leak in the xrdb patch, that I was unable to fix.

I hope this is helpful, let me know, what you think of it.

Hi!

I'm currently using the vanitygaps patch and was wondering if it is possible to make monocle mode have outergaps (similar to tiling mode with just one window).

Thanks in advanced!

I suspect this is a case of my ignorance not a bug, but..

Scenario: Using Chromium, the "Save File" window exceeds my display resolution, 4k, which requires RMB drag and LMB to decrease size to select save or cancel.

1. Using RULE(.title = "Save File", .isfloating = 1, .floatpos = "50% 50% 50% 50%" ) in config.h does not appear to effect the targeted window. I have enabled the patch in patches.h.
2. Regarding https://github.com/bakkeby/patches/wiki/floatpos can you add an example of floatpos rule in a rule table? My attempts to add "50% 50% 50% 50%" and other values for floatpos fail. I am confident that I am not using the appropriate syntax.

~> xprop
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MODAL
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x1000001
WM_TRANSIENT_FOR(WINDOW): window id # 0xe00002
_GTK_THEME_VARIANT(UTF8_STRING) = 
XdndAware(ATOM) = BITMAP
_NET_WM_OPAQUE_REGION(CARDINAL) = 0, 0, 3848, 2844
WM_WINDOW_ROLE(STRING) = "GtkFileChooserDialog"
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 16777230, 16777231
_NET_WM_USER_TIME(CARDINAL) = 18314636
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x100000d
WM_CLIENT_LEADER(WINDOW): window id # 0x1000001
_NET_WM_PID(CARDINAL) = 66445
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "soc262890"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 1254 by 850
		program specified resize increment: 2 by 2
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "chrome", "Chrome"
WM_ICON_NAME(STRING) = "Save File"
_NET_WM_ICON_NAME(UTF8_STRING) = "Save File"
WM_NAME(STRING) = "Save File"
_NET_WM_NAME(UTF8_STRING) = "Save File"

Love what you do @bakkeby. Thank you!

Hello, first of all let me just say that I'm amazed at your work with these patches and the dwm-flexipatch thing, amazing, amazing..

I think I found a bug with the current diff for the barmodules-awesomebar patch. Clicking on the bar is not working.

That happened after I applied some patches prior to the awesomebar one but just to be sure it wasn't some other patches before I went and applied it on a clean build. Only barmodules and then awesomebar and it still didn't work.

I'm also investigating if there are issues with dwm-barmodules-status2d-statuscmd-dwmblocks-extrastatus, my bar went away after applying it, but i'm not sure if it's configuration or wrong patching. I assume that goes instead of the status2d patch right? it seemed to include it, so idk. anyways..

Hey again, sorry to keep spamming your github page. Figured this is better than reaching out on reddit. There a couple minor issues that are easily reproduced when using the fake fullscreen client functionality of the fullscreen compilation patch. Tested with a bare dwm (latest commit).

From what I can gather, most of these issues can be prevented by enabling actual fullscreen at any point before going into fakefullscreen mode (with the exception if 2.1 outlined below).

1 : When toggling fakefullscreen on any client on and then off, it removes the border of that client. However, if you go into actual fullscreen mode at any point before going into fakefullscreen mode, the client behaves as expected. Fake/actual fullscreen can now be toggled in any order and the borders remain.

Steps to reproduce:

• select a tiled client
• toggle fakefullscreen off/on, watch the border disappear
• select a new tiled client
• toggle actualfullscreen
• exit fullscreen and then toggle fakefullscreen repeatedly; the borders should remain constant now, and the client should behave

2 : On floating clients, entering fakefullscreen works the first time, but exiting fakefullscreen removes the border in addition to placing it back in its tiled position. While the client is floating, going into actual fullscreen mode at any point before fakefullscreen prevents this as well.

Steps to reproduce:

• select a tiled client and toggle floating on
• while floating, toggle fakefullscreen off/on, watch the border disappear and the client revert to the tiled position in the stack
• select a new tiled client make it float, then toggle actual fullscreen
• with the client now in fullscreen, toggle fakefullscreen repeatedly and everything should behave

2.1 : In an attempt to isolate issue 2, I discovered another odd scenario relating to floating clients:

Steps to reproduce:

• select a tiled client and make it fullscreen, then toggle fullscreen off again
• make that same client floatling
• toggle fakefullscreen on
• toggle fakefullscreen off; now the client's borders should remain intact, yet it still reverts back to the tiled position in the stack
• making the same client fullscreen at any point while it is floating fixes this

3 : This last one is probably related to unfocus(). If you focus on a client and toggle actual fullscreen first, and then exit out of it by toggling fake fullscreen, the client loses focus in favor of the client where the mouse cursor is. In this scenario, the borders are fine, and the client goes into fakefullscreen - it just loses focus in favor of the mouse position. If the client is made fullscreen while already in fakefullscreen, toggling fakefullscreen off exits both of the fullscreen modes, which I'd say is the expected behavior.

Steps to reproduce:

• select a client, make it fullscreen
• now make it fakefullscreen
• the client should now be properly in a tiled fake fullscreen mode, but the cursor position will determine which client has focus
• select the client that has fakefullscreen active
• make it actual fullscreen
• toggle fakefullscreen off, now the client should be in a normal tiled state

To summarize:

Fakefullscreen introduces some unexpected behavior when it is the first action called on any selected client. Nearly all of these issues can be prevented by calling actualfullscreen on the client at any point before fakefullscreen. The only instance where this is not the case is outlined in issue 2.1. Issue 3 remains mostly unaffected by this as well, as it has to do with the order the fullscreen modes are initialized.

Just wanted to bring this to your attention. I'm not sure where to look to even attempt to fix this myself, but I'm guessing clientmessage(), configurenotify(), and unfocus(). Any clue why fakefullscreen behaves this way? How is it so interlocked between the order in which fakefullscreen and actual fullscreen is called, in addition to the client state (tiled vs floating)?

Hopefully this post is detailed enough to give you something to work with. I'm happy to test out anything you'd like me to change in my build of dwm and report back, and I'll of course share anything else I discover.

I have the suspicion that there is a but somewhere in the placemouse patch. Sometimes dwm randomly crashes, when I try to move a window between monitors. It is very hard to reproduce, so I have no idea what exactly causes the crash. Just thought I might put it here if somebody encounters similar problems or has an idea of what the problem might be.

I can reproduce it most of the time with two windows on the first monitor and then moving one to the second monitor. If I then let go the mouse button, when the window is almost fully on the next monitor and only about 20/30 pixels still on the first monitor it doesn't snap in as it should. If I then try to move it again dwm crashes. If I use the top bar to change the tag it just attaches to that new tag, without crashing.

When using the fullscreen patch to turn a windowed window into a fullscreen window does it still have the performance of a windowed window or the higher performance of a fullscreen window?

Hi!

I'm currently using this patch of swallow in my dwm build. (Patch dated: 2020/07/07)

When invoking my pdf viewer through the terminal, at times, the adjacent terminal window gets swallowed. Not sure if this is fixed in the latest patch on the website or not.

tldl, scratchpad terminal windows don't swallow.

The scratchpad patch uses the instance 'property' of the window. Seems to be ignoring the class of isterminal or something I don't quite understand.

Just curious if you notice or happen to stumble across this behaviour.

When swallowing in a fullscreen terminal window, the new client spawns in floating mode (with messed up geometry). This has been fixed in Luke's build LukeSmithxyz/dwm@7d73565.

Hi, i apply your barpadding patch, but i think it has conflict with status2d. the patch doesn't throw any errors but the colors in status2d got broken, it is working before i add the barpadding patch. im using vanilla dwm 6.3. thank you sir

When I have one window open on any layout, it simply reverts back to tiling layout.

Could you please make changes, such that this patch works exclusively when in tiling layout mode only?

If I have a window that is assigned to multiple tags, for example if a window is assigned to tags 1 and 2, if I am currently viewing windows with tag 1 and I swap it to the other monitor, when I swap back the window only retains tag 1.
Is it possible to store the windows assigned tags before the swap, and restore them when swapping back?

Hey again, I'm having this problem for a while now but I haven't pay attention to much. I only like to have fakefullscreen by default on firefox, then I fullscreen something within the browser and it works fine but then if you tried to fullscreen again the fakefullscreen window isn't resize correctly (on the botton right weridly).
Just today before making this issue I copied your RULE macro and use it on my rules array and it is nice to have, so thanks.

Hi @bakkeby thanks for making the bottomtabs patch for tabbed , it doesnt seem to work for me . And the tabs arent clickable with mouse either and the tabs arent visible. Also they just show when I make the terminal fullscreen.

I'm using flexipatch and wanted to separately align different text elements on the status bar, for example having text aligned to the left and right edges while also having one piece centered (see picture). Is there a way to create a third status element like with the extrastatus patch? I tried copying the code responsible for that patch but it just draws the same status in the middle.

Great patch nonetheless, thank you for putting it together.

On my current build, I'm using the scratchpads patch. When patched along with shiftviewclients and cycling through non-empty tags, the hidden scratchpads appear on the screen. I don't suppose this is the intended behaviour.

In my config.h, I have the following:

static const char *muttscratchcmd[] = {"s", "st", "-n", "muttscratch", "-g", "130x28", "-e", "neomutt", NULL};
static const char *pulsescratchcmd[] = {"s", "st", "-n", "pulsescratch", "-g", "100x28", "-e", "pulsemixer", NULL};
static const char *yubiscratchcmd[] = {"s", "yubioath-desktop", NULL};
static const char *whatsscratchcmd[] = {"s", "whatsdesk", NULL};
static const char *topscratchcmd[] = {"s", "st", "-n", "topscratch", "-g", "100x28", "-e", "htop", NULL};

RULE(.instance = "muttscratch", .scratchkey = 's', .isfloating = 0)
RULE(.instance = "pulsescratch", .scratchkey = 's', .isfloating = 0)
RULE(.instance = "yubioath-desktop", .scratchkey = 's', .isfloating = 1)
RULE(.instance = "whatsdesk", .scratchkey = 's', .isfloating = 1)
RULE(.instance = "topscratch", .scratchkey = 's', .isfloating = 0)

{ MODKEY|ControlMask,           XK_m,          togglescratch,          {.v = muttscratchcmd } },
{ MODKEY|ControlMask,           XK_p,          togglescratch,          {.v = pulsescratchcmd } },
{ MODKEY|ControlMask,           XK_y,          togglescratch,          {.v = yubiscratchcmd } },
{ MODKEY|ControlMask,           XK_w,          togglescratch,          {.v = whatsscratchcmd } },
{ MODKEY|ControlMask,           XK_t,          togglescratch,          {.v = topscratchcmd } },

I might be doing something wrong, but when I press, say, mod+control+m, to toggle the mutt scratchpad, it'll open just fine. Though, if the mutt scratchpad has already been opened, pressing, say, mod+control+p, will toggle mutt again, instead of pulsemixer.

EDIT: I am using this patch from dwm-flexipatch.

to put it simply. having a specific status for each monitor. much like splitstatus splits for center, it splits for monitors

my only usecase for this is to ONLY tell the time. (i could just launch a terminal or set a hotkey for this but why even bother?) i use a custom dwm build with holdbar to save some screen estate. but i would like to know the time as i have a second monitor.

i can use staticstatus but my current status-bar configuration is quite large and doesn't fit on my secondary display.

offtopic question:
just as a question, is it even appropriate for ask for patch requests here?
and, why aren't some of your patches on the dwm.suckless.org patches?

Hello,

I finally finished fully patching dwm and just want to say: thank you for riospawn and rioresize! They are perfect! I am having one issue though, I use dwmc to get all bindings using sxhkd. The issue I am facing is that for some reason rioresize() does not always resize the selected window to the desired location. This seems odd and I can't determine why this is happening.

I have the following sxhkd binding to resize the current window using rioresize and in my config.def.h I do create a wrapper function for dwm-signal (my dwmc). I can't seem to resolve this issue and was wondering if it is an issue in upstream. I have not changed rioresize.