corbet@stout.ucar.edu (Jonathan Corbet) (06/23/89)
A couple days ago I posted a question about an awm problem I have noticed, wherein awm will go into an infinite loop occasionally when f.iconify is invoked from a mouse button. I asked if anybody else had checked into it, but didn't get any affirmative responses, so I started digging, and I have an idea as to what is happening. The following line appears in my .awmrc file: f.iconify= m :window|icon: left down Awm implements this by doing a passive grab on the left button with the meta modifier on all top-level windows in the tree. When that button is pushed, the grab becomes active, and the event is delivered to awm as usual. Here comes the rub: awm then unmaps the window, and plunks an icon down somewhere else on the screen instead. This seems to terminate the grab, although I haven't seen anything in the book to say that this should happen. (I'm not saying it isn't there -- I just didn't see it). If you don't let up on the mouse button quickly enough, the ButtonRelease event is delivered to whatever window is under the cursor *now*, instead of the one which was iconified. If the event propagates back to the root window, awm seems to get it anyway, and everything is OK. If, however, the window under the pointer receives button events of its own (i.e. xterm, text widget, or xev), then that client gets the event, awm never sees it, and it busy waits until it gets a different button event from somewhere. So, the problem can now be easily reproduced: simply stack two xterms one on top of the other, iconify the top one with a button defined as above, and don't release the button until the iconified window is gone. Now I have a couple of different questions. (1) Is the passive grab mechanism really working the way I think it is, and is that the way it is supposed to work, and (2) any ideas for how to fix this problem? I am not sure why awm busy waits for the release event, but given that it does, my feeling is that awm should just do an active grab on the pointer to be sure that it gets that release event. Comments? (Details: Xsun 11.3, gcc) Thanks, Jonathan Corbet National Center for Atmospheric Research, Field Observing Facility corbet@stout.ucar.edu
tom@ICASE.EDU (Tom Crockett) (06/23/89)
> *Excerpts from xpert: 22-Jun-89 Awm infinite loop problem r.. Jonathan* > *Corbet@ohio-sta (2207)* > The following line appears in my .awmrc file: > f.iconify= m :window|icon: left down As a workaround you might try using "left up" instead of "left down". I haven't noticed any problem with that. It also lets you change your mind in mid-click by moving the mouse out of the window or icon before you let up on the button (but be careful about what the root window does with "left up"!). Tom Crockett ICASE Institute for Computer Applications in Science and Engineering M.S. 132C e-mail: tom@icase.edu NASA Langley Research Center phone: (804) 864-2182 Hampton, VA 23665-5225
karlton@fudge.sgi.com (Phil Karlton) (06/24/89)
In article <3512@ncar.ucar.edu> corbet@stout.ucar.edu (Jonathan Corbet) writes: >Now I have a couple of different questions. (1) Is the passive grab >mechanism really working the way I think it is, and is that the way it >is supposed to work, and (2) any ideas for how to fix this problem? I >am not sure why awm busy waits for the release event, but given that >it does, my feeling is that awm should just do an active grab on the >pointer to be sure that it gets that release event. Comments? (1) Yes and yes. On page 381 of the Digital Press "X Window System" book it says (under the description for UngrabPointer) An UngrabPointer request is performed automatically if the event window or confine-to window for an active pointer grab becomes not viewable or ... (2) One thing awm could be doing is to grab the button syncronously, and then "convert" the pointer grab to be asyncronous and relative to the root window by doing an appropriate GrabPointer call. PK
jdi@franz.COM (John Irwin) (06/24/89)
Your message:
A couple days ago I posted a question about an awm problem I have noticed,
wherein awm will go into an infinite loop occasionally when f.iconify is
invoked from a mouse button. I asked if anybody else had checked into it,
but didn't get any affirmative responses, so I started digging, and I have
an idea as to what is happening.
The following line appears in my .awmrc file:
f.iconify= m :window|icon: left down
...
Jonathan Corbet
National Center for Atmospheric Research, Field Observing Facility
corbet@stout.ucar.edu
--------
I had the same problem, but was told it didn't exist. :-)
Here is the fix:
*** /tmp/Iconify.c Fri Jun 23 14:50:07 1989
- - --- Iconify.c Tue Feb 28 13:48:21 1989
***************
*** 230,234 ****
status = XWarpPointer (dpy, None, to,
0, 0, 0, 0,
toInfo.width / 2, toInfo.height / 2);
! Leave(FALSE)
}
- - --- 230,234 ----
status = XWarpPointer (dpy, None, to,
0, 0, 0, 0,
toInfo.width / 2, toInfo.height / 2);
! Leave(TRUE)
}
I don't know how this fix interacts with iconification if you use the up
event as another poster suggested. But it does fix the problem if you
use down events.
-- John Irwin, jdi@franz.com