DWM Hackers Unite! Share (or request) dwm patches.

thayer · 2013-03-07 05:25:12

Unia wrote:

Otherwise, you can look at my GitHub. I still have my XFT and systray patches up there for DWM 6.0.

Thanks again. Your patches worked, when the others failed.

One thing I've noticed is that the up/down arrow characters that I used with pango no longer work with the Xft patches; same font as before (arial), but they appear as blocks now. Oh well, I'm pretty easy to please :)

Army · 2013-03-07 08:20:02

ivoarch wrote:

Yes you are right Army,
clicking on the tags doesn't work right.
I found this http://lists.suckless.org/dev/1208/12107.html

Ah right, I remember this post, but back then I thought I already have this, so I don't need it. But this one looks a bit more simple than what I posted.

andmars · 2013-03-07 09:24:26

I'm wondering: is ther a single-window-no-border patch that also works with the bstack patch?

Army · 2013-03-07 10:05:35

Yes

diff -paur dwm.old/dwm.c dwm.new/dwm.c
--- dwm.old/dwm.c	2012-12-14 21:13:02.818037177 +0100
+++ dwm.new/dwm.c	2012-12-14 21:13:07.648082669 +0100
@@ -1360,7 +1360,13 @@ resizeclient(Client *c, int x, int y, in
 	c->oldy = c->y; c->y = wc.y = y;
 	c->oldw = c->w; c->w = wc.width = w;
 	c->oldh = c->h; c->h = wc.height = h;
-	wc.border_width = c->bw;
+	if(selmon->wx == c->x && selmon->wy == c->y && selmon->ww - 2 * c->bw == c->w && selmon->wh - 2 * c->bw == c->h && !c->isfloating && !c->isfullscreen) {
+		wc.border_width = 0;
+		c->w = wc.width += c->bw * 2;
+		c->h = wc.height += c->bw * 2;
+	}
+	else
+		wc.border_width = c->bw;
 	XConfigureWindow(dpy, c->win, CWX|CWY|CWWidth|CWHeight|CWBorderWidth, &wc);
 	configure(c);
 	XSync(dpy, False);

That one works for every layout.

ANOKNUSA · 2013-03-07 14:21:40

andmars wrote:

I'm wondering: is ther a single-window-no-border patch that also works with the bstack patch?

I've been using both without any problems for as long as I've been using DWM. Check your patching order. Army's solution may be better though, if you use many layouts and pertag (maybe, I don't use pertag myself).

Unia · 2013-03-08 17:46:48

Here's a quick one I just came up with: when there is only one client visible (in Tile/Bstack layout), use Monocle instead. When more clients are spawned, it automatically switches back to the layout it was set to (e.g. Tile=Monocle -> Tile). It's diffed against a patched dwm.c, but as it's really trivial I thought I could share it anyway:

--- src/dwm-6.0/dwm.c	2013-03-08 18:43:08.565408608 +0100
+++ b/dwm-6.0/dwm.c	2013-03-08 18:42:28.615409280 +0100
@@ -1775,21 +1775,25 @@
 	if(n == 0)
 		return;
 
-	if(n > m->nmasters[m->curtag])
-		mw = m->nmasters[m->curtag] ? m->ww * m->mfacts[m->curtag] : 0;
-	else
-		mw = m->ww;
-	for(i = my = ty = 0, c = nexttiled(m->clients); c; c = nexttiled(c->next), i++)
-		if(i < m->nmasters[m->curtag]) {
-			h = (m->wh - my) / (MIN(n, m->nmasters[m->curtag]) - i);
-			resize(c, m->wx, m->wy + my, mw - (2*c->bw), h - (2*c->bw), False);
-			my += HEIGHT(c);
-		}
-		else {
-			h = (m->wh - ty) / (n - i);
-			resize(c, m->wx + mw, m->wy + ty, m->ww - mw - (2*c->bw), h - (2*c->bw), False);
-			ty += HEIGHT(c);
-		}
+	if(n == 1) {
+		monocle(selmon);
+	} else {
+		if(n > m->nmasters[m->curtag])
+			mw = m->nmasters[m->curtag] ? m->ww * m->mfacts[m->curtag] : 0;
+		else
+			mw = m->ww;
+		for(i = my = ty = 0, c = nexttiled(m->clients); c; c = nexttiled(c->next), i++)
+			if(i < m->nmasters[m->curtag]) {
+				h = (m->wh - my) / (MIN(n, m->nmasters[m->curtag]) - i);
+				resize(c, m->wx, m->wy + my, mw - (2*c->bw), h - (2*c->bw), False);
+				my += HEIGHT(c);
+			}
+			else {
+				h = (m->wh - ty) / (n - i);
+				resize(c, m->wx + mw, m->wy + ty, m->ww - mw - (2*c->bw), h - (2*c->bw), False);
+				ty += HEIGHT(c);
+			}
+	}
 }
 
 void
@@ -2225,22 +2229,25 @@
 	for(n = 0, c = nexttiled(m->clients); c; c = nexttiled(c->next), n++);
 	if(n == 0)
 		return;
-
-	if(n > m->nmasters[m->curtag])
-		mh = m->nmasters[m->curtag] ? m->wh * m->mfacts[m->curtag] : 0;
-	else
-		mh = m->wh;
-	for(i = mx = tx = 0, c = nexttiled(m->clients); c; c = nexttiled(c->next), i++)
-		if(i < m->nmasters[m->curtag]) {
-			w = (m->ww - mx) / (MIN(n, m->nmasters[m->curtag]) - i);
-			resize(c, m->wx + mx, m->wy, w - (2*c->bw), mh - (2*c->bw), False);
-			mx += WIDTH(c);
-		}
-		else {
-			w = (m->ww - tx) / (n - i);
-			resize(c, m->wx + tx, m->wy + mh, w - (2*c->bw), m->wh - mh - (2*c->bw), False);
-			tx += WIDTH(c);
-		}
+	if(n == 1) {
+		monocle(selmon);
+	} else {
+		if(n > m->nmasters[m->curtag])
+			mh = m->nmasters[m->curtag] ? m->wh * m->mfacts[m->curtag] : 0;
+		else
+			mh = m->wh;
+		for(i = mx = tx = 0, c = nexttiled(m->clients); c; c = nexttiled(c->next), i++)
+			if(i < m->nmasters[m->curtag]) {
+				w = (m->ww - mx) / (MIN(n, m->nmasters[m->curtag]) - i);
+				resize(c, m->wx + mx, m->wy, w - (2*c->bw), mh - (2*c->bw), False);
+				mx += WIDTH(c);
+			}
+			else {
+				w = (m->ww - tx) / (n - i);
+				resize(c, m->wx + tx, m->wy + mh, w - (2*c->bw), m->wh - mh - (2*c->bw), False);
+				tx += WIDTH(c);
+			}
+	}
 }
 
 int

mkaito · 2013-03-10 04:25:52

Army wrote:

Yes

diff -paur dwm.old/dwm.c dwm.new/dwm.c
--- dwm.old/dwm.c	2012-12-14 21:13:02.818037177 +0100
+++ dwm.new/dwm.c	2012-12-14 21:13:07.648082669 +0100
@@ -1360,7 +1360,13 @@ resizeclient(Client *c, int x, int y, in
 	c->oldy = c->y; c->y = wc.y = y;
 	c->oldw = c->w; c->w = wc.width = w;
 	c->oldh = c->h; c->h = wc.height = h;
-	wc.border_width = c->bw;
+	if(selmon->wx == c->x && selmon->wy == c->y && selmon->ww - 2 * c->bw == c->w && selmon->wh - 2 * c->bw == c->h && !c->isfloating && !c->isfullscreen) {
+		wc.border_width = 0;
+		c->w = wc.width += c->bw * 2;
+		c->h = wc.height += c->bw * 2;
+	}
+	else
+		wc.border_width = c->bw;
 	XConfigureWindow(dpy, c->win, CWX|CWY|CWWidth|CWHeight|CWBorderWidth, &wc);
 	configure(c);
 	XSync(dpy, False);

That one works for every layout.

This never removes the border for me. It usually fails the condition check, no idea why, but even when it correctly detects a lonely window, it doesn't remove the border at all. Still derping around with fprintf, trying to find the problem...

Army · 2013-03-10 10:30:41

Strange ... but well, there are other patches around, so no big harm

mkaito · 2013-03-10 16:54:46

The other ones I found make dwm segfault on me xD

Unia · 2013-03-10 17:38:02

What other patches are you using? Maybe they conflict with one another

mkaito · 2013-03-10 18:14:25

I can't see anything that would conflict with how borders are configured... But please check out my dwm config at https://github.com/mkaito/dwm

Unia · 2013-03-11 21:05:10

Hello everyone,

I have two things I need help with; they're the only things left I want to change that I can't do alone, I think.

1. I want to change the multimonitor handling of DWM: I don't want a double tagset, nor a singular (as mkaito uses); I want to have my second monitor have one single tag I can send clients to from my main monitor, which has all the standard tags. Kind of how GNOME Shell handles multi monitors.
2. I want to change the borders on clients. Having them like MonsterWM has them (no double borders between two clients, but overlapping) would be a start. Preferable, I would have that and no borders on screen edges (left/bottom/right)

I'm not familiar with either of these things in DWM, so if anyone could give me a pointer on where to look that'd be great! I'm going to take a look at the singular patchset right now to see if that can be altered.

Thanks!

synorgy · 2013-03-12 13:14:22

Unia wrote:

I don't want a double tagset, nor a singular (as mkaito uses); I want to have my second monitor have one single tag I can send clients to from my main monitor, which has all the standard tags. Kind of how GNOME Shell handles multi monitors.

I'm not sure how feasible this is. mkaito's single tagset approach changes a LOT of underlying behavior, and this sort of request changes a lot more. What WOULD be feasible, I believe, would be changing the bar drawing and keybind code to SHOW only one tag on the second monitor and to disable the switching of tags if the second monitor has focus. Would that be a reasonable enough change? I'm not sure I'll have time to look at this in the near future, but the approach seems to fulfill your request and not to require too many changes.

Unia wrote:

I want to change the borders on clients. Having them like MonsterWM has them (no double borders between two clients, but overlapping) would be a start. Preferable, I would have that and no borders on screen edges (left/bottom/right)

This would be a bit of an undertaking as well, though it wouldn't be as large a request as above. Mostly this would require offsetting window placement and width by some combination of border width. The code itself would be simple, but modifying the source in every possible place would be time consuming. I would start by looking at monocle() and then at tile(). You would also need to ensure that the active window always gets raised to the top (so that the active border for that window is not obscured by the overlapping borders), which is something that DWM doesn't currently handle (though this is pretty simple. Check out this for a nudge in the right direction)

Unia · 2013-03-12 15:34:55

synorgy wrote:

I'm not sure how feasible this is. mkaito's single tagset approach changes a LOT of underlying behavior, and this sort of request changes a lot more. What WOULD be feasible, I believe, would be changing the bar drawing and keybind code to SHOW only one tag on the second monitor and to disable the switching of tags if the second monitor has focus. Would that be a reasonable enough change? I'm not sure I'll have time to look at this in the near future, but the approach seems to fulfill your request and not to require too many changes.

I thought it'd actually require less changes than the single tagset patch. I'm not sure how the multimonitor thing works in DWM, but can't we do it like this:
1. Create the main monitor, which is the laptop screen. (already implemented)
2. If more monitors get attached (also already implemented), create a new tag solely on this monitor. (not implemented, because as we know currently it creates a whole new tagset).

synorgy wrote:

This would be a bit of an undertaking as well, though it wouldn't be as large a request as above. Mostly this would require offsetting window placement and width by some combination of border width. The code itself would be simple, but modifying the source in every possible place would be time consuming. I would start by looking at monocle() and then at tile(). You would also need to ensure that the active window always gets raised to the top (so that the active border for that window is not obscured by the overlapping borders), which is something that DWM doesn't currently handle (though this is pretty simple. Check out this for a nudge in the right direction)

I had a go at this last night and I could get the double borders between the master client and the stack to dissapear. However, the stack's border simply overlapped the master client's one as you said. I didn't know about XRaiseWindow so will see if that can help solve this. For monocle(), I have already done this: I keep the border at the top and the others are simply moved "off the screen" (so in a multimonitor setup, you will see them on the second monitor)

Unia · 2013-03-12 22:59:05

Oke I got a bit further with the borders: now all borders on the screen edges are removed (left/bottom/right; they are simply placed off-screen) and the double borders between the clients are gone. ~~I do still have the overlapping border issue, so for example when master has focus and we switch to the stack, you will see master's unfocused border because it overlaps the stack's focused border.~~ I did find out however, that once I give the stack focus with MODKEY+mouseclick, it gets moved to the top so you see the correct border.

tl;dr when I click (with MODKEY) the client to give focus the borders work correctly; when I only move my mouse into the client (and it gets focus) the border does not work correctly.

EDIT: borders do work as they should when you navigate the clients with the keyboard. So, actually, it's just the focusfollowmouse without click that's not working properly. Does anybody know how to fix that?

Last edited by Unia (2013-03-13 00:42:32)

Unia · 2013-03-13 00:42:17

All fixed! It took one call to XRaiseWindow inside focus(), thanks for the pointer on that one synorgy! You can find the complete patch on my GitHub!

Unia · 2013-03-13 15:50:21

I found out that when one has a floating client and changes focus to a tiled client, the tiled client will be raised and overlap the floating one. I'm going to look into this, but again, if someone knows a (possible) fix before I find it it'd be appreciated!

Last edited by Unia (2013-03-13 15:50:35)

synorgy · 2013-03-13 17:30:23

Glad you managed to figure the border issue out, Unia.

With regard to a separate tagset on a second monitor (with a different definition than the first), you might be able to get away with using a second tag 'struct' (quotes because I'm not sure that's how it's handled) and applying that struct to all monitors after the first one. I might find some time this coming weekend to look into this more. I'd be interested in seeing if I couldn't get a single tagset working with less intrusive changes than mkaito's solution, so I should be looking into this before long anyway.

Unia · 2013-03-13 17:50:15

synorgy wrote:

With regard to a separate tagset on a second monitor (with a different definition than the first), you might be able to get away with using a second tag 'struct' (quotes because I'm not sure that's how it's handled) and applying that struct to all monitors after the first one. I might find some time this coming weekend to look into this more. I'd be interested in seeing if I couldn't get a single tagset working with less intrusive changes than mkaito's solution, so I should be looking into this before long anyway.

Sorry if my initial explanation wasn't that clear I look forward to what you come up with!

mkaito · 2013-03-15 16:34:28

Would anyone know how to handle tagging of wine virtual desktops via their name attribute? It seems wine delays setting it, and tagging is done before it happens. Bad behavior on wine's part, alright, but I'm looking at different ways to handle it in dwm. Ideas?

Unia · 2013-03-16 22:32:19

Does anyone know how to detect if a client is on top in the stack? I'm modifying push.c so it only moves window in the stack (to move windows to master, we have the zoom() function already).

I succesfully managed to do that, but now when I push a client up that is on top it will "loop" through all the clients in the stack and place it on the bottom. I'd like to prevent this and not move the window, so I need to detect if the window is on top of the stack. Here's my code so far (would also appreciate if someone could check this and see if I approached this correctly):

static Client *
prevtiled(Client *c) {
    Client *p, *r;

    for(p = selmon->clients, r = NULL; p && p != c; p = p->next)
        if(!p->isfloating && ISVISIBLE(p))
            r = p;
    return r;
}

static void
pushup(const Arg *arg) {
    Client *sel = selmon->sel, *c;

    if(!sel || sel->isfloating)
        return;
    if((c = prevtiled(sel))) {
        /* attach before c */
        detach(sel);
        if(c == nexttiled(selmon->clients))
            sel->next = NULL;
        else
            sel->next = c;
        for(c = selmon->clients; c->next != sel->next; c = c->next);
            c->next = sel;
    }
    focus(sel);
    arrange(selmon);
}

static void
pushdown(const Arg *arg) {
    Client *sel = selmon->sel, *c;

    if(!sel || sel->isfloating)
        return;
    if((c = nexttiled(sel->next))) {
        /* attach after c */
        detach(sel);
        sel->next = c->next;
        c->next = sel;
    }
    focus(sel);
    arrange(selmon);
}

Last edited by Unia (2013-03-16 22:33:12)

mkaito · 2013-03-18 01:04:27

mkaito wrote:

Army wrote:

Yes

diff -paur dwm.old/dwm.c dwm.new/dwm.c
--- dwm.old/dwm.c	2012-12-14 21:13:02.818037177 +0100
+++ dwm.new/dwm.c	2012-12-14 21:13:07.648082669 +0100
@@ -1360,7 +1360,13 @@ resizeclient(Client *c, int x, int y, in
 	c->oldy = c->y; c->y = wc.y = y;
 	c->oldw = c->w; c->w = wc.width = w;
 	c->oldh = c->h; c->h = wc.height = h;
-	wc.border_width = c->bw;
+	if(selmon->wx == c->x && selmon->wy == c->y && selmon->ww - 2 * c->bw == c->w && selmon->wh - 2 * c->bw == c->h && !c->isfloating && !c->isfullscreen) {
+		wc.border_width = 0;
+		c->w = wc.width += c->bw * 2;
+		c->h = wc.height += c->bw * 2;
+	}
+	else
+		wc.border_width = c->bw;
 	XConfigureWindow(dpy, c->win, CWX|CWY|CWWidth|CWHeight|CWBorderWidth, &wc);
 	configure(c);
 	XSync(dpy, False);

That one works for every layout.

This never removes the border for me. It usually fails the condition check, no idea why, but even when it correctly detects a lonely window, it doesn't remove the border at all. Still derping around with fprintf, trying to find the problem...

Found the problem. I was sticking it in manage() instead of resizeclient(). The woes of trying to patch a heavily patched dwm.c...

EDIT: It correctly removes the border when a window is displayed alone, but restores it when I view a tag on another monitor. Strange as hell...

Last edited by mkaito (2013-03-18 03:25:16)

Army · 2013-03-18 09:45:46

mkaito wrote:

It correctly removes the border when a window is displayed alone, but restores it when I view a tag on another monitor. Strange as hell...

Do you mean, that the borders are there, if you e.g. move a client to an empty tag on another monitor? Because in that case the border reappears too on my machine. I hardly move windows, so I never looked into it..

illusionist · 2013-03-18 10:14:32

Unia wrote:

Does anyone know how to detect if a client is on top in the stack?

You may use _NET_CLIENT_LIST atom for a query. There are few other functions you can try like XGetWindowProperty() and XFetchName(). DWM has some functions that may be useful, take a look at gestate() and getatomprop(). See here for some EWMH reference .

Last edited by illusionist (2013-03-18 10:16:58)

Unia · 2013-03-18 15:52:48

illusionist wrote:

Unia wrote:
Does anyone know how to detect if a client is on top in the stack?
You may use _NET_CLIENT_LIST atom for a query. There are few other functions you can try like XGetWindowProperty() and XFetchName(). DWM has some functions that may be useful, take a look at gestate() and getatomprop(). See here for some EWMH reference .

I'm not sure that's what I need. The stack is only something DWM is aware of, AFAIK. Thanks though.

Arch Linux

#1126 2013-03-07 05:25:12

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1127 2013-03-07 08:20:02

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1128 2013-03-07 09:24:26

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1129 2013-03-07 10:05:35

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1130 2013-03-07 14:21:40

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1131 2013-03-08 17:46:48

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1132 2013-03-10 04:25:52

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1133 2013-03-10 10:30:41

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1134 2013-03-10 16:54:46

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1135 2013-03-10 17:38:02

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1136 2013-03-10 18:14:25

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1137 2013-03-11 21:05:10

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1138 2013-03-12 13:14:22

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1139 2013-03-12 15:34:55

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1140 2013-03-12 22:59:05

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1141 2013-03-13 00:42:17

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1142 2013-03-13 15:50:21

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1143 2013-03-13 17:30:23

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1144 2013-03-13 17:50:15

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1145 2013-03-15 16:34:28

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1146 2013-03-16 22:32:19

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1147 2013-03-18 01:04:27

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1148 2013-03-18 09:45:46

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1149 2013-03-18 10:14:32

Re: DWM Hackers Unite! Share (or request) dwm patches.

#1150 2013-03-18 15:52:48

Re: DWM Hackers Unite! Share (or request) dwm patches.

Board footer