Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
Hey,
On 8 August 2011 04:58, Valentin Ochs a...@0au.de wrote:
Just found http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4
So apparently the help window wants to go into WithdrawnState, get
ignored by dwm, and draw its own icon or whatever right after being
mapped. Makes sense to me...
Reading the ICCCM standard, it does seem to be a bug in Mathematica:
The client should unmap the window and follow it with a synthetic
UnmapNotify event, but in fact all it seems to do is send the
synthetic event on its own. Not to mention that mapping the window and
then immediately asking to be withdrawn makes absolutely no sense.
For compatibility with obsolete clients, window managers should
trigger the transition to the Withdrawn state on the real UnmapNotify
rather than waiting for the synthetic one. They should also trigger
the transition if they receive a synthetic UnmapNotify on a window for
which they have not yet received a real UnmapNotify.
At the moment dwm makes no distinction between real and synthetic
UnmapNotify events, which means it does (for all intents and purposes)
seem to abide by the standard. But apparently Mathematica is broken.
Valentin's patch, although it apparently works, does quite abide by
the standard, in that it completely ignores synthetic UnmapNotify
events rather than setting the state hint appropriately. What I think
we should do is this:
if((c = wintoclient(ev-window))) {
if(ev-send_event)
setclientstate(c, WithdrawnState);
else
unmanage(c, False);
}
That way we abide by the standard, even if that means we set the state
to Withdrawn when it, well, isn't. I blame Mathematica for that one.
(Valentin, could you check whether this breaks the patch for Mathematica?)
Thanks,
cls
Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
On Mon, Aug 08, 2011 at 04:43:31PM +0100, Connor Lane Smith wrote:
if((c = wintoclient(ev-window))) {
if(ev-send_event)
setclientstate(c, WithdrawnState);
else
unmanage(c, False);
}
That way we abide by the standard, even if that means we set the state
to Withdrawn when it, well, isn't. I blame Mathematica for that one.
(Valentin, could you check whether this breaks the patch for Mathematica?)
Nope, still works fine.
--Valentin
Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
On 8 August 2011 18:10, Valentin Ochs a...@0au.de wrote:
On Mon, Aug 08, 2011 at 04:43:31PM +0100, Connor Lane Smith wrote:
if((c = wintoclient(ev-window))) {
if(ev-send_event)
setclientstate(c, WithdrawnState);
else
unmanage(c, False);
}
That way we abide by the standard, even if that means we set the state
to Withdrawn when it, well, isn't. I blame Mathematica for that one.
(Valentin, could you check whether this breaks the patch for Mathematica?)
Nope, still works fine.
I'm happy to incorporate those changes. Thanks for your investigation!
Cheers,
--garbeam
[dev] [dwm] [patch] USPosition, USSize
Hey,
I've recently been looking into dwm's window manager hints support.
I've just finished looking through all the ICCCM properties (next up
EWMH), and have found only one which dwm ought to support, but
doesn't: the WM_NORMAL_HINTS USPosition and USSize fields.
Basically these two fields state that the client's geometry has been
chosen specifically by the user, and the window manager ought to
respect that. But we don't, we just tile the window anyway. The
traditional X utilities all set this field when the user passes them
the '-geom' (or similar) flag, including xterm, rxvt, and so on.
I've attached a patch which adds support for these fields in updatesizehints().
Thanks,
cls
diff -r 335c279dbff6 dwm.c
--- a/dwm.c Tue Jun 14 22:28:16 2011 +0100
+++ b/dwm.c Tue Aug 09 03:07:52 2011 +0100
@@ -1882,6 +1882,8 @@
if(!XGetWMNormalHints(dpy, c-win, size, msize))
/* size is uninitialized, ensure that size.flags aren't used */
size.flags = PSize;
+ if(size.flags (USPosition|USSize))
+ c-isfloating = True;
if(size.flags PBaseSize) {
c-basew = size.base_width;
c-baseh = size.base_height;
Re: [dev] [dwm] [patch] USPosition, USSize
On Mon, Aug 8, 2011 at 10:08 PM, Connor Lane Smith c...@lubutu.com wrote: Basically these two fields state that the client's geometry has been chosen specifically by the user, and the window manager ought to respect that. But we don't, we just tile the window anyway. The traditional X utilities all set this field when the user passes them the '-geom' (or similar) flag, including xterm, rxvt, and so on. This might be the historical reason these exist, but they were conceived before the advent of modern tiling window managers, and imo clients shouldn't be managing themselves anyway. Further, there's no telling what kind of weird-ass program might be abusing these without anyone as yet knowing. Please don't merge this patch into mainline; I'd like xterm et al to behave just they way they have been. -- # Kurt H Maier
