Issue 96 in xmonad: certain dialogs get dropped in gnucash

older
darcs patch: man/xmonad.hs: add...

codesite-noreply＠google.com

8 Dec 2007 8 Dec '07

9:16 p.m.

Issue 96: certain dialogs get dropped in gnucash http://code.google.com/p/xmonad/issues/detail?id=96 Comment #1 by jcreigh: This is definitely an xmonad bug, as the problem does not occur if Gnucash windows are ignored (with, eg, className =? "Gnucash" --> doIgnore) Issue attribute updates: Status: Started -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

Show replies by date

Thomas Adam

9 Dec 9 Dec

5:07 a.m.

New subject: Issue 96 in xmonad: certain dialogs get dropped in gnucash

Hi -- On 09/12/2007, codesite-noreply@google.com wrote:

...

Issue 96: certain dialogs get dropped in gnucash http://code.google.com/p/xmonad/issues/detail?id=96

Comment #1 by jcreigh: This is definitely an xmonad bug, as the problem does not occur if Gnucash windows are ignored (with, eg, className =? "Gnucash" --> doIgnore)

I bet I know what this bug is (I;m assuming transient windows here): The window is being mapped and unmapped. If you were to use something like xscope then you might see that: a) Application sends a mapRequest. a1) Before xmonad has a chance to do that, the application asks to be put in the WithDrawn state (via a synthetic UnmapNotify event). b) The window is mapped. c) GNUCash sends a MapRequest. d) Another UnmapNotify request is sent and the window is UnMapped. e) The MapRequest from (c) is handled and a real UnMapNotify request is issued causing the window it close, never being mapped again. I'm guessing this is what's happening, but I don't run GnuCash. -- Thomas Adam

Andrew Sackville-West

10 Dec 10 Dec

12:13 p.m.

New subject: Issue 96 in xmonad: certain dialogs get dropped in gnucash

On Sun, Dec 09, 2007 at 10:07:34AM +0000, Thomas Adam wrote:

...

Hi --

On 09/12/2007, codesite-noreply@google.com wrote:

...
Issue 96: certain dialogs get dropped in gnucash http://code.google.com/p/xmonad/issues/detail?id=96

Comment #1 by jcreigh: This is definitely an xmonad bug, as the problem does not occur if Gnucash windows are ignored (with, eg, className =? "Gnucash" --> doIgnore)

I bet I know what this bug is (I;m assuming transient windows here):

The window is being mapped and unmapped. If you were to use something like xscope then you might see that:

a) Application sends a mapRequest. a1) Before xmonad has a chance to do that, the application asks to be put in the WithDrawn state (via a synthetic UnmapNotify event). b) The window is mapped. c) GNUCash sends a MapRequest. d) Another UnmapNotify request is sent and the window is UnMapped. e) The MapRequest from (c) is handled and a real UnMapNotify request is issued causing the window it close, never being mapped again.

Anyone feel like clueing me in on what this really means? It sounds to me, from my minimal understanding of the above list, like GnuCash may be at fault (or at least one it's libs -- gtk?) and xmonad is just listening to what it says instead of gracefully ignoring conflicting requests. But I'm no gui nor WM programmer, so I'd love a little education :) A

Thomas Adam

2:44 p.m.

New subject: Issue 96 in xmonad: certain dialogs get dropped in gnucash

Hi -- On 10/12/2007, Andrew Sackville-West wrote:

...

On Sun, Dec 09, 2007 at 10:07:34AM +0000, Thomas Adam wrote:

...
a) Application sends a mapRequest. a1) Before xmonad has a chance to do that, the application asks to be put in the WithDrawn state (via a synthetic UnmapNotify event). b) The window is mapped. c) GNUCash sends a MapRequest. d) Another UnmapNotify request is sent and the window is UnMapped. e) The MapRequest from (c) is handled and a real UnMapNotify request is issued causing the window it close, never being mapped again.

Anyone feel like clueing me in on what this really means? It sounds to me, from my minimal understanding of the above list, like GnuCash may be at fault (or at least one it's libs -- gtk?) and xmonad is just listening to what it says instead of gracefully ignoring conflicting requests.

No -- the window manager is doing what it has been told to do, the problem is with what the ICCCM says about how to handle such cases. I should point out I have no idea if the issue reported is what I have outlined or not, I'm simply guessing. A window can be mapped and in the WithDrawn state (i.e., not displayed) on screen. The long and short of what I've detailed there is that should a MapRequest is followed by a synthetic (fake) UnmapNotify request it should simply ignore the MapRequest, since it will map it properly when the real MapRequest is issued. -- Thomas Adam

Jason Creighton

11 Dec 11 Dec

2:24 a.m.

New subject: Issue 96 in xmonad: certain dialogs get dropped in gnucash

On Sun, Dec 09, 2007 at 10:07:34AM +0000, Thomas Adam wrote:

...

Hi --

On 09/12/2007, codesite-noreply@google.com wrote:

...
Issue 96: certain dialogs get dropped in gnucash http://code.google.com/p/xmonad/issues/detail?id=96

Comment #1 by jcreigh: This is definitely an xmonad bug, as the problem does not occur if Gnucash windows are ignored (with, eg, className =? "Gnucash" --> doIgnore)

I bet I know what this bug is (I;m assuming transient windows here):

The window is being mapped and unmapped. If you were to use something like xscope then you might see that:

a) Application sends a mapRequest. a1) Before xmonad has a chance to do that, the application asks to be put in the WithDrawn state (via a synthetic UnmapNotify event). b) The window is mapped. c) GNUCash sends a MapRequest. d) Another UnmapNotify request is sent and the window is UnMapped. e) The MapRequest from (c) is handled and a real UnMapNotify request is issued causing the window it close, never being mapped again.

I'm guessing this is what's happening, but I don't run GnuCash.

Thanks for the pointer. I think I've found the issue, but I'm not 100% sure it's the same one that you're describing. What I'm seeing is this: 1) Gnucash sends a MapRequest event 2) Gnucash sends a synthetic UnmapNotify event 3) Gnucash sends a MapRequest event agin. I don't know why Gnucash does it that way., it's just what seems to be happening from the trace. Presumably there's a reason. 4) xmonad maps the window, in response to (1) 5) xmonad unmaps the window, in response to (2) 6) xmonad receives an UnmapNotify in response to (5), but it isn't processed yet, because we still haven't even got to (3) 7) xmonad maps the window again, in response to (3) 8) xmonad unmaps the window, due to the UnmapNotify we got in (6) and have just now got around to processing. (This account of the events is reconstructed from a xmond [sic] trace of xmonad, so this is the order that xmonad received them. Obviously an event trace doesn't tell me *why* xmonad is doing these things, I'm infering that from looking at the event processing code. So there's a chance that I'm wrong about which code path is being taken when xmonad maps or unmaps a window.) Now, we have a waitingUnmap Map to record how many unmaps we can safely ignore, but unmange looks like this: unmanage w = do windows (W.delete w) setWMState w withdrawnState modify (\s -> s {mapped = S.delete w (mapped s), waitingUnmap = M.delete w (waitingUnmap s)}) "windows" will call "hide" on the no-longer-visible window, which will increment waitingUnmap and remove that window from "mapped". But then "unmanage" clears "waitingUnmap" after that, which is why in (8) xmonad doesn't ignore the UnmapNotify like it should. And indeed, if you comment out that line in "unmanage", the gnucash find dialog works fine. So now I'm wondering why unmanage does that in the first place when it seems like letting "hide" handle it would be fine. On #xmonad, sjanssen mentioned the issue of avoiding a space leak, so that's one concern to keep in mind. Jason Creighton

Thomas Adam

2:46 a.m.

New subject: Issue 96 in xmonad: certain dialogs get dropped in gnucash

Hello -- On 11/12/2007, Jason Creighton wrote:

...

Now, we have a waitingUnmap Map to record how many unmaps we can safely ignore, but unmange looks like this:

Yup. As I mentioned in #xmonad, the way to deal with this to ignore the MapRequest if following it is a synthetic UnmapNotify request, since the real events follow shortly anyway. -- Thomas Adam

6371

Age (days ago)

6373

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Andrew Sackville-West
codesite-noreply＠google.com
Jason Creighton
Thomas Adam