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

jgr · 2016-01-22 17:51:36

4bytes wrote:

    "DejaVu Sans:size=10.5",

I've narrowed it down, it's the font you're using. I don't want to be the guy that tells you what font to use but changing to "DejaVu Sans Mono" will get rid of the issue until I figure why this particular font is causing truncation.

EDIT: I've compiled a list of fonts that I've found this issue in by sight and opened an issue on my patches repo, you can track progress there.

Last edited by jgr (2016-01-22 19:36:41)

4bytes · 2016-01-23 10:37:49

Thank you rgr!

I have changed the font and re-applied your patch and now I don't have aforesaid bug
Also I subscribed to the issue that you have created, thanks

If I can help you somehow please let me know.

Ocypheum · 2016-01-27 04:23:23

Great job jgr - much better than the fix I came up with. Do you want to put it on the dwm wiki?

jgr · 2016-01-31 13:22:28

Ocypheum wrote:

Great job jgr - much better than the fix I came up with. Do you want to put it on the dwm wiki?

Thanks, I will submit it to the dwm wiki when I'm sure it works properly. As it is I still need to fix the font bug, but I've got another break from uni soon so I can do it then.

sesese9 · 2016-02-12 04:07:56

I've started to look around at other people's dwms and didn't know if anyone has a patch or way to change the rectangle to a line on tags that are active on dwm HEAD? If so, can you post it please?
Link to kinda what I'm drawing inspiration from: http://frankshin.com/wp-content/uploads … nbusy1.png

Last edited by sesese9 (2016-02-12 04:08:59)

Trilby · 2016-02-12 12:18:10

sesese9, I haven't used dwm in quite a while, but I did make similar changes in mine when I used it.

All that is required is a revision to line 728 of dwm.c to something like the following:

drw_rect(drw, x, bh-4, w, 4, ...

You may want to play with the value of "4" in both parameters (keep them the same) to suit your tastes.

Note, though that this will draw a filled bar when dwm would normally have a filled square and an empty bar when dwm would normally have an empty square. If you want to eliminate the latter, just remove the "occ & 1 << i" parameter in that line a replace it with a 0.

sesese9 · 2016-02-18 21:19:14

Trilby wrote:

sesese9, I haven't used dwm in quite a while, but I did make similar changes in mine when I used it.
All that is required is a revision to line 728 of dwm.c to something like the following:
drw_rect(drw, x, bh-4, w, 4, ...
You may want to play with the value of "4" in both parameters (keep them the same) to suit your tastes.
Note, though that this will draw a filled bar when dwm would normally have a filled square and an empty bar when dwm would normally have an empty square. If you want to eliminate the latter, just remove the "occ & 1 << i" parameter in that line a replace it with a 0.

Thx, Trilby! That was actually what I wanted!

Bayart · 2016-03-01 07:57:33

Does anyone have a functioning status colors patch for the latest git revision (3465bed) ? The 6.1 one from the suckless git repo just completely fucks up dwm on my side.

jasonwryan · 2016-03-01 08:02:14

jgr's patch several posts up works great...

Bayart · 2016-03-01 08:39:55

jasonwryan wrote:

jgr's patch several posts up works great...

Yes, I randomly followed his signature to victory earlier, and came to edit my post out. Too late...

Last edited by Bayart (2016-03-01 08:40:30)

hungerfish · 2016-03-02 19:19:47

So, about fullscreen programs...
I would like to call upon the collective mind power of the hive to clarify the situation for me!

As I'm a gamer, I occasionally run some games, and this sometimes leads to problems with dwm.
Some games implement fullscreen modes differently than others, since some games work just fine, whilst others don't.
Some behaviours I've observed:
- video players just work.
- game switches to fullscreen mode, keeps resolution, works fine.
- game switches to fullscreen mode, switches resolution, focus goes to game, but all I see it a distorted desktop at the wrong resolutions.
An example 'game' would be dosbox, so its not just 'legacy cruft stuff'
- Game switches to 'something', I get a '0x0' window with just the borders drawn around it (so kinda a grey square in my case),
the game runs fine in the background though, resizing is not possible, layout switching is seemingly ignored.

So obviously I would like to fix this somehow, as this doesn't seem to be a problem with other wms(I've tried marco and openbox).
I briefly scanned the patches list on suckless, but didn't see anything related, anyone got a solution, or more general pointers?

Trilby · 2016-03-02 19:29:37

hungerfish, there likely isn't a (single) good solution as many games (and many game engines) are known to not work with non-reparenting WMs like dwm.

I've recently been struggling with this with my own non-reparenting WM with a program I'm working on that uses SFML. There is a bug report on the current version of SFML but it doesn't seem to be getting much attention. My solution was to work around the SFML issue in my SFML program's code - there was no way for me to work around the issue in my WMs code.

There will be work-arounds here and there, but these are not one-size fits all: they will be different for different gui libs used in these games. So the fix for SFML will not be the same one needed for SDL, or SDL2, or openGL, or java. These each present their own incompatibilities with non-reparenting WMs and many of them have their own workarounds which can be found.

Perhaps the only solution that could be implemented in dwm is to actually turn it into a reparenting WM for clients in a given list (like existing client rules). But this would be no small task.

hungerfish · 2016-03-02 20:12:39

I have literately zero knowledge of the X11 protocol, what signals exist and how they all connect so I guess I should rephrase and try to look for workarounds for these specific 'types' of problems...
For me the most annoying is the case of programs switching resolutions. because they leave your with a non working desktop.
Manually using xrandr to switch between resolutions works just fine!

EDIT:
So it seems that I wasn't quite up to date with my dwm-code-base.
Specifically I was missing this commit, which seems to fix the resolution/focus loss problem,
at least with dosbox for me!

Last edited by hungerfish (2016-05-13 07:05:13)

null · 2016-03-05 13:55:01

@jgr,
I've just replaced the statuscolor patch with yours. Finally the gap between different colors is gone

But I've got another problem in combination with a centerclock patch: the status line between the tiling mode indicator and clock and also between the clock and the status text is just pure black [1].
That's how I draw the statusline:

void
drawbar(Monitor *m)
{
        int x, xx, w, dx, clockw;
        time_t current;
        char clock[38];
        unsigned int i, occ = 0, urg = 0;
        Client *c;

        dx = (drw->fonts[0]->ascent + drw->fonts[0]->descent + 2) / 4;

        for (c = m->clients; c; c = c->next) {
                occ |= c->tags;
                if (c->isurgent)
                        urg |= c->tags;
        }
        x = 0;
        for (i = 0; i < LENGTH(tags); i++) {
                w = TEXTW(tags[i]);
                drw_setscheme(drw, &scheme[(m->tagset[m->seltags] & 1 << i) ? 1 : (urg & 1 << i ? 2 : 0)]);
                drw_text(drw, x, 0, w, bh, tags[i], 0); 
                drw_rect(drw, x + 1, 1, dx, dx, m == selmon && selmon->sel && selmon->sel->tags & 1 << i,
                         occ & 1 << i, 0);
                x += w;
        }
        w = blw = TEXTW(m->ltsymbol);
        drw_setscheme(drw, &scheme[0]);
        drw_text(drw, x, 0, w, bh, m->ltsymbol, 0);
        x += w;
        xx = x;
        if (m == selmon) { /* status is only drawn on selected monitor */
                w = drw_get_width(drw, NUMCOLORS, stext);
                x = m->ww - w;
                if (x < xx) {
                        x = xx;
                        w = m->ww - xx;
                } 
                drw_colored_text(drw, scheme, NUMCOLORS, x, 0, w, bh, stext);
        } else
                x = m->ww;
        if ((w = x - xx) > bh) {
                time(&current);
                strftime(clock, 38, clock_fmt, localtime(&current));
                clockw = TEXTW(clock);
                x = xx;

                drw_setscheme(drw, &scheme[0]);
                drw_text(drw, (m->mw / 2) - (clockw / 2), 0, clockw, bh, clock, 0);
        }
        drw_map(drw, m->barwin, 0, 0, m->ww, bh);
}

(Full code @ https://github.com/null-git/dotfiles/bl … -6.1/dwm.c and the patch: https://github.com/null-git/dotfiles/bl … clock.diff )
Do you (or anyone else) have any idea where this could come from?

Cheers

[1] Screenshot: http://s9.postimg.org/jwmfpcpi7/2016_03 … _scrot.png

Edit: The black part seems not to be redrawn at all. If my status text shrinks in size it leaves parts of the old text behind..

Edit2: After refreshing my C knowledge a bit and having a bit of try and error fun I narrowed the problem down to the positioning of the clock:

drw_text(drw, (m->mw / 2) - (clockw / 2), 0, clockw, bh, clock, 0);

If I use "(m->mw / 2) - (clockw / 2)" for the start position instead of x, the bar before the clock becomes black and won't be drawn. Also, if I use "clockw" instead of w for the width, everything after the clock is black. So the price question is: how to draw the clock in the middle without messing everything up?
Previously it was done with

drawtext(NULL, dc.norm, False);
dc.w = MIN(dc.w, clockw);
dc.x = MAX(dc.x, (m->mw / 2) - (clockw / 2));
drawtext(clock, dc.sel, False);

but the dc struct doesn't seem to exist anymore..

Edit3: Solution for now (quick'n'dirty hacking and still would prefere another solution..):

drw_setscheme(drw, &scheme[0]);
drw_text(drw, x, 0, w, bh, "", 0);
drw_text(drw, (m->mw / 2) - (clockw / 2), 0, clockw, bh, clock, 0);

Last edited by null (2016-03-05 15:19:45)

mahatman2 · 2016-05-04 02:12:47

Hope I'm not necro-bumping this thread, but here's a patch that only gives shadows to floating windows (so they look more "floaty" compared to the tiled windows). I've done it by setting the COMPTON_SHADOW XProperty, which compton can use to selectively apply shadows. Obviously, this patch requires compton to work, and this line in compton.conf:

shadow-exclude = [ "_COMPTON_SHADOW:32c = 0" ];

Without further ado, the patch (I'll figure out getting it onto github at some point):

diff --git a/dwm.c b/dwm.c
index ff7e096..cccd865 100644
--- a/dwm.c
+++ b/dwm.c
@@ -203,6 +203,7 @@ static void setfullscreen(Client *c, int fullscreen);
 static void setlayout(const Arg *arg);
 static void setmfact(const Arg *arg);
 static void setup(void);
+static void shadowfloat(Client *c);
 static void showhide(Client *c);
 static void sigchld(int unused);
 static void spawn(const Arg *arg);
@@ -259,6 +260,7 @@ static void (*handler[LASTEvent]) (XEvent *) = {
 	[UnmapNotify] = unmapnotify
 };
 static Atom wmatom[WMLast], netatom[NetLast];
+static Atom wunshadow;
 static int running = 1;
 static Cur *cursor[CurLast];
 static ClrScheme scheme[SchemeLast];
@@ -813,6 +815,7 @@ focus(Client *c)
 		attachstack(c);
 		grabbuttons(c, 1);
 		XSetWindowBorder(dpy, c->win, scheme[SchemeSel].border->pix);
+		shadowfloat(c);
 		setfocus(c);
 	} else {
 		XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
@@ -1081,6 +1084,7 @@ manage(Window w, XWindowAttributes *wa)
 		c->isfloating = c->oldstate = trans != None || c->isfixed;
 	if (c->isfloating)
 		XRaiseWindow(dpy, c->win);
+	shadowfloat(c);
 	attach(c);
 	attachstack(c);
 	XChangeProperty(dpy, root, netatom[NetClientList], XA_WINDOW, 32, PropModeAppend,
@@ -1387,6 +1391,8 @@ restack(Monitor *m)
 				wc.sibling = c->win;
 			}
 	}
+	for (c = m->stack; c; c = c->snext)
+		shadowfloat(c);
 	XSync(dpy, False);
 	while (XCheckMaskEvent(dpy, EnterWindowMask, &ev));
 }
@@ -1580,6 +1586,7 @@ setup(void)
 	netatom[NetWMWindowType] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE", False);
 	netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE_DIALOG", False);
 	netatom[NetClientList] = XInternAtom(dpy, "_NET_CLIENT_LIST", False);
+	wunshadow = XInternAtom(dpy, "_COMPTON_SHADOW", False);
 	/* init cursors */
 	cursor[CurNormal] = drw_cur_create(drw, XC_left_ptr);
 	cursor[CurResize] = drw_cur_create(drw, XC_sizing);
@@ -1609,6 +1616,17 @@ setup(void)
 }
 
 void
+shadowfloat(Client *c)
+{
+	if (!c->isfloating && selmon->lt[selmon->sellt]->arrange) {
+		unsigned long shadow[] = { 0x00000000 };
+		XChangeProperty(dpy, c->win, wunshadow, XA_CARDINAL, 32, PropModeReplace, (unsigned char *)shadow, 1);
+	} else {
+		XDeleteProperty(dpy, c->win, wunshadow);
+	}
+}
+
+void
 showhide(Client *c)
 {
 	if (!c)
@@ -1714,6 +1732,7 @@ togglefloating(const Arg *arg)
 	if (selmon->sel->isfloating)
 		resize(selmon->sel, selmon->sel->x, selmon->sel->y,
 		       selmon->sel->w, selmon->sel->h, 0);
+	shadowfloat(selmon->sel);
 	arrange(selmon);
 }

archpony · 2016-05-19 09:20:04

Hi, everyone!
Let me introduce you a yet another statusbar for dwm. The reason behind: no patches required for dwm, good ol' C, no insane process spawning to get some trivial numbers. Current capabilities:

date/time
used memory
CPU usage
space available on FS
keyboard layout
IP address
volume level
battery charge level

You can get it from here:
https://github.com/archpony/ponybar

Critique, suggestions and feature requests are more than welcome.

Trilby · 2016-05-19 14:17:15

Nice archpony. But one suggestion I'd have which may lead to a substantial performance gain is to not connect and disconnect to the XServer every time through the loop. Just connect once at the beginning, and keep it open as long as you need it.

You can see how I did this in a simple example here or for a much more well maintained and flexible version see Unia's fork.

You might also check out how the linked examples allow some checks to run every time through the loop, while others only run once every minute or few minutes. Many checks don't need as fine-scale of a resolution as cpu or ram usage and not running them every second will also save a lot of resources.

Unia · 2016-05-19 16:37:37

Trilby wrote:

much more well maintained and flexible version see Unia's fork.

Eh, I haven't touched it for almost two years

Trilby · 2016-05-19 17:53:03

Yeah, but that's much more recently that I've done anything with mine

archpony · 2016-05-20 07:36:14

Thank you very much, Trilby. I shall definitely implement your suggestions.

BeiNacht · 2016-11-12 17:13:35

if someone also needs it.
https://github.com/BeiNacht/dwm/blob/ma … bined.diff
i combined flextile and cfacts. Cfacts is also working for horizontal splitts

totolotto · 2017-02-25 07:06:20

1. After patching 6.1 with systray I get this warning. Everything seems to be working fine but nevertheless do you know how to get rid of this warning?

dwm.c: In function ‘configurenotify’:
dwm.c:663:4: warning: ‘m’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    resizebarwin(m);
    ^

2. I am trying to run a bash script in dwm. This solution works:

static const char *menucmd[]  = { "sh", "menuscript", NULL };

but I would like to build my "menuscript" in the code. I have found how to do this, but with my limited C knowledge I cannot figure out how to link "system(menuscript);" to a keybinding in config.h.

Thanks!

Trilby · 2017-02-25 12:11:49

totolotto, using system() is really not the right approach. You'd be better with fork() + exec(). Of course fork+exec is exactly what dwm natively does. So why do you want to try to override that and do something worse?

I suspect you may want to get rid of the need to start "sh" and run "menuscript" within that sh session given that you really just want to run "menuscript". Two problems with that, first, system() implicitly calls "sh", it just hides it; so you could use the following, assuming "menuscript" is executable:

static const char *menucmd[]  = { "/path/to/menuscript", NULL };

The second problem is, though, that menuscript is a shell script, so it will start a shell interpreter anyways.

There is zero advantage of using system(). Don't.

EDIT: oh, I see the real purpose might actually be to prevent having an additional file and having the bash commands embedded in the dwm binary. This is bad for many reasons. That takes away the only reason to use shell scripts: that they can be edited without having to recompile. Every single change you then make to your script code would require recompiling dwm. Second, you will make it ridiculously easy to arbitrary code to be executed. This is one of the critiques of using system() at all, even when it is just given a filename to a script - but this is much much more of a problem when all the script is embeded as a string literal within the binary.

What is your end goal? Why do you think this would be a good thing to do? This looks a lot like an X-Y problem.

totolotto · 2017-02-25 12:56:52

Yes my goal is to get rid of the "extra" file from my home folder, that's why i wanted to include my menuscript in dwm source code - even if i understand your points.

Trilby · 2017-02-25 13:50:20

If you just want it out of your home folder, move it somewhere else.

What's in the script? If it's just flags for dmenu, the just launch dmenu with those flags.

Arch Linux

#1476 2016-01-22 17:51:36

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

#1477 2016-01-23 10:37:49

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

#1478 2016-01-27 04:23:23

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

#1479 2016-01-31 13:22:28

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

#1480 2016-02-12 04:07:56

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

#1481 2016-02-12 12:18:10

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

#1482 2016-02-18 21:19:14

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

#1483 2016-03-01 07:57:33

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

#1484 2016-03-01 08:02:14

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

#1485 2016-03-01 08:39:55

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

#1486 2016-03-02 19:19:47

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

#1487 2016-03-02 19:29:37

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

#1488 2016-03-02 20:12:39

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

#1489 2016-03-05 13:55:01

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

#1490 2016-05-04 02:12:47

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

#1491 2016-05-19 09:20:04

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

#1492 2016-05-19 14:17:15

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

#1493 2016-05-19 16:37:37

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

#1494 2016-05-19 17:53:03

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

#1495 2016-05-20 07:36:14

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

#1496 2016-11-12 17:13:35

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

#1497 2017-02-25 07:06:20

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

#1498 2017-02-25 12:11:49

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

#1499 2017-02-25 12:56:52

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

#1500 2017-02-25 13:50:20

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

Board footer