diff -r 014df3c34b64 dwm.c
--- a/dwm.c Sat Jun 25 09:07:04 2011 +0100
+++ b/dwm.c Sat Jun 25 22:46:04 2011 +0200
@@ -827,13 +827,14 @@
if((ev->mode != NotifyNormal || ev->detail == NotifyInferior) &&
ev->window != root)
return;
c = wintoclient(ev->window);
-
Couldn't dwm map newly created windows *after* they have been moved
to their proper position? Less flickering (especially noticeable with
the attachabove/attachaside patches), and it feels snappier on a slow
computer.
I haven't experienced any problems with the attached patch so far.
Peter
diff -
Hi Anselm,
> I reviewed your patch and concluded I can't apply it as is, because
> focus() would be called twice, once on the unmapped window, and then
> on again.
It seems to me that focusing and arranging should be independent
operations. So here comes another patch to remove focus(NULL) from
a
> just one annoying issue with floating apps. eg. running save as in gimp,
> will open a window in the background.
Oh man, sorry. I should've tested it more with floating windows.
So arrange calls arrangemon, which calls restack, but the new floating
window hasn't become selmon->sel yet.
Restack
> To prevent the first restack, maybe something like the attached patch?
... which causes the title bar to flicker, as restack calls drawbar
before bailing out. Not sure why that's needed.
Peter
Hi,
> void
> grabkeys(void) {
> + unsigned int i, j;
> + unsigned int modifiers[] = { 0, LockMask, numlockmask,
> numlockmask|LockMask };
> + KeyCode code;
> +
> updatenumlockmask();
> - {
> - unsigned int i, j;
> - unsigned int modifiers[] = { 0, L
So here's another go at mapping new windows after everything has
been arranged.
This time, floating windows are stacked correctly and there are
no flickers or redraws of the title bar or the new window. The
two patches add 8 short lines. Seems not too gross as an interim
solution.
The line "c->mo