On Fri, Dec 13, 2002 at 08:20:29AM -0500, Dan Espen wrote: > Dominik Vogt <fvwm-workers@fvwm.org> writes: > > On Thu, Dec 12, 2002 at 03:46:18PM -0500, Dan Espen wrote: > > > Dan Espen <[EMAIL PROTECTED]> writes: > > > > > > > > I've been trying to debug this, but I'm pretty much stuck. > > > > I've been working off the workers list, but in this case, > > > > I'm copying the list since I'm out of ideas, and I see something > > > > pretty strange. > > > > > > Further developments: > > > > > > I find I can't create the problem in an Xnest window, > > > but I can on :0. Thats seems very consistent. > > > > > > Using prints, I see that HandleUnmapNotify calls > > > destroy_window leading to the window the main window > > > being destroyed. > > > > > > HandleUnmapNotify doesn't seem to get called inside Xnest. > > > > > > I think what I need to do is print more of the information > > > about the event. Right now, I have no idea how to do that, > > > or what to look for, > > > so I have to do more research. Of course, hints would be > > > appreciated. > > > > Add this after the "if (!fw)" clause in HandleUnmalNotify(): > > > > fprintf(stderr, > > "hun: w=0x%08x f=0x%08x, synthetic=%d '%s'\n", > > (int)te->xunmap.event, te->xunmap.send_event, > > (int)fw, (fw) ? fw->visible_name : "(null"); > > > > te->xunmap.event is the client window id that was unmapped. If > > te->xunmap.send_event is true, the client requested transition to > > withdrawn state. > > Gee, maybe I'm not hopeless, I already have all that. > Here's what I gathered: > > AddWindow: entered > AddWindow: window 8164FE0, window name is RAID Manager - dog.bert.sun.fi > AddWindow: entered > AddWindow: window 815FBD0, window name is About... > HandleUnmapNotify: calling destroy_window 815FBD0, event C00026, window > c00026, Root 26, send_event 0 > destroy_window: entered > destroy_window: About... > HandleDestroyNotify: calling destroy_window > destroy_window: entered > HandleDestroyNotify: calling destroy_window > destroy_window: entered > HandleDestroyNotify: calling destroy_window > destroy_window: entered > HandleDestroyNotify: calling destroy_window > destroy_window: entered > HandleDestroyNotify: calling destroy_window > destroy_window: entered > HandleUnmapNotify: calling destroy_window 8164FE0, event C00012, window > c00012, Root 26, send_event 0 > destroy_window: entered > destroy_window: RAID Manager - dog.bert.sun.fi > HandleDestroyNotify: calling destroy_window > destroy_window: entered > HandleDestroyNotify: calling destroy_window > destroy_window: entered > HandleDestroyNotify: calling destroy_window > destroy_window: entered
So, either fvwm unmapped the window or the application unmapped it. But the application definitely did not ask fvwm to withdraw the window. Do you get an XDestroyNotify event for the window too? > The debug statement in HandleUnmapNotify looks like this: > > fprintf(stderr,"HandleUnmapNotify: calling destroy_window %X, event %X, > window %X, Root %X, send_event %X\n", > (int)fw,(int)te->xunmap.event, > (int)te->xunmap.window, > (int)Scr.Root, > (int)te->xunmap.send_event); > > What you labeled as "synthetic" I've got labeled as "window". > I wanted to know if it was a synthetic event, but I didn't know > how to do that. What value would fw have if it was synthetic? If the client window has a frame is should be a pointer to the window structure, and NULL otherwise. The send_event member does not affect fw. > In destroy_window, theres one statment showing entry and another > when fw is non-zero. > > > > Doesn't an Unmap event indicate the application has unmapped > > > itself? > > > > No, fvwm gets an XUnmapNotify when the X server unmaps a client > > window. It does not matter why the window was unmapped.. I can't > > think of anything else but to find all places where > > XUnmapWindow(), XDestroyWindow() or XWithdrawWindow() is called for > > a client window throughout the fvwm core and print debug output for > > each (et least the window id and the title). > > OK, I think you are saying that there are other places a window > can get unmapped/destroyed/withdrawn by fvwm other than destroy_window. > I'll try to find all the other places and see if I can trace them. I don't see any XWithdrawWindow() and XDestroyWindow() calls (as expected), but there are several XUnmapWindow() calls. I forgot to mention XReparentWindow(), which unmaps the window if it was already mapped. Perhaps you could just comment out all XUnampWindow() calls on the client window and all Reborder() calls for the moment. If this still happens we can safely assume that the application unmapped or destroyed the window itself. > > But to be honest, I > > don't expect much to come out of the whole debug session. Since > > you said that the app tries to be its own window manager, I > > strongly suspect that its doing something terribly wrong. > > Good. Thats my feeling too. > The actual application executable has a name that ends in .EXE, > (a sure sign of trouble). But I don't think this is another one > of those Mainsoft applications (like Rational Rose). > > > It may help to watch the events flying around prior to the window > > being unmapped. > > We don't seem to have any debug logic that produces a trace of events. > It seems like it would be pretty useful. I often put in a lot of debug statements, but in general I am only interested in a few events, but with very detailed output. One big debug switch wouldn't work too well - we'd need more control over the debug level and the verbosity of each event type. Bye Dominik ^_^ ^_^ -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
