Re: [dev] [patch] map new window *after* arrange()
On 10 July 2011 03:39, Peter Hartlich bq...@hartlich.com wrote: 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. I reverted your map modifications in the 5.9 release. I think this is a good candidate for the upcoming 6.0 series, which will incorporate several structural changes. Cheers, --garbeam
Re: [dev] [patch] map new window *after* arrange()
Hi Peter, On 9 July 2011 00:40, Peter Hartlich bq...@hartlich.com wrote: 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 arrange and add it, if missing, everywhere arrange is called after either a window might have vanished from selmon's view, or selmon itself might have vanished. I agree with this and applied both patches. It is not my ideal solution, but I postpone an ideal version for 6.0. All, please test hg tip. If there are no issues this will become 5.9 tomorrow. Cheers, --garbeam
Re: [dev] [patch] map new window *after* arrange()
On Sat, Jul 9, 2011 at 10:01, garbeam garb...@gmail.com wrote: Hi Peter, On 9 July 2011 00:40, Peter Hartlich bq...@hartlich.com wrote: 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 arrange and add it, if missing, everywhere arrange is called after either a window might have vanished from selmon's view, or selmon itself might have vanished. I agree with this and applied both patches. It is not my ideal solution, but I postpone an ideal version for 6.0. All, please test hg tip. If there are no issues this will become 5.9 tomorrow. Cheers, --garbeam just one annoying issue with floating apps. eg. running save as in gimp, will open a window in the background.
Re: [dev] [patch] map new window *after* arrange()
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. Restacking again at the end of manage fixes it, but then there's another redraw. To prevent the first restack, maybe something like the attached patch? Or split off (un)select functions from (un)focus, which also came up in connection to virtual keyboards some time ago. Regards, Peter --- dwm/dwm.c.orig 2011-07-10 02:34:59.982409153 +0200 +++ dwm/dwm.c 2011-07-10 03:49:19.114387186 +0200 @@ -1150,9 +1150,12 @@ manage(Window w, XWindowAttributes *wa) attachstack(c); XMoveResizeWindow(dpy, c-win, c-x + 2 * sw, c-y, c-w, c-h); /* some windows require this */ setclientstate(c, NormalState); + unfocus(selmon-sel, False); + selmon-sel = NULL; arrange(c-mon); XMapWindow(dpy, c-win); focus(c); + restack(c-mon); } void
Re: [dev] [patch] map new window *after* arrange()
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
Re: [dev] [patch] map new window *after* arrange()
Hi Peter, 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. I'm thinking about modifying your patch to avoid this. Cheers, garbeam PS: On Sunday there is dwm's official 5th birthday and I consider dedicating the 5.9 release for this purpose :)
Re: [dev] [patch] map new window *after* arrange()
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
arrange and add it, if missing, everywhere arrange is called after
either a window might have vanished from selmon's view, or selmon
itself might have vanished.
Regards,
Peter
--- dwm/dwm.c.orig 2011-07-09 01:21:43.924293041 +0200
+++ dwm/dwm.c 2011-07-09 01:25:06.127245938 +0200
@@ -389,7 +389,6 @@ arrange(Monitor *m) {
showhide(m-stack);
else for(m = mons; m; m = m-next)
showhide(m-stack);
- focus(NULL);
if(m)
arrangemon(m);
else for(m = mons; m; m = m-next)
@@ -598,6 +597,7 @@ configurenotify(XEvent *e) {
updatebars();
for(m = mons; m; m = m-next)
XMoveResizeWindow(dpy, m-barwin, m-wx, m-by,
m-ww, bh);
+ focus(NULL);
arrange(NULL);
}
}
@@ -1616,6 +1616,7 @@ void
tag(const Arg *arg) {
if(selmon-sel arg-ui TAGMASK) {
selmon-sel-tags = arg-ui TAGMASK;
+ focus(NULL);
arrange(selmon);
}
}
@@ -1696,6 +1697,7 @@ toggletag(const Arg *arg) {
newtags = selmon-sel-tags ^ (arg-ui TAGMASK);
if(newtags) {
selmon-sel-tags = newtags;
+ focus(NULL);
arrange(selmon);
}
}
@@ -1706,6 +1708,7 @@ toggleview(const Arg *arg) {
if(newtagset) {
selmon-tagset[selmon-seltags] = newtagset;
+ focus(NULL);
arrange(selmon);
}
}
@@ -1971,6 +1974,7 @@ view(const Arg *arg) {
selmon-seltags ^= 1; /* toggle sel tagset */
if(arg-ui TAGMASK)
selmon-tagset[selmon-seltags] = arg-ui TAGMASK;
+ focus(NULL);
arrange(selmon);
}
[dev] [patch] map new window *after* arrange()
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 -r c787646ca93f dwm.c --- a/dwm.c Sat Jul 02 11:01:58 2011 +0200 +++ b/dwm.c Wed Jul 06 22:55:49 2011 +0200 @@ -1149,9 +1149,10 @@ attach(c); attachstack(c); XMoveResizeWindow(dpy, c-win, c-x + 2 * sw, c-y, c-w, c-h); /* some windows require this */ - XMapWindow(dpy, c-win); setclientstate(c, NormalState); arrange(c-mon); + XMapWindow(dpy, c-win); + focus(c); } void
Re: [dev] [patch] map new window *after* arrange()
Hi Peter, On 6 July 2011 23:15, Peter Hartlich bq...@hartlich.com wrote: 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. your patch looks alright to me, I intend to apply it. Cheers, --garbeam
