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
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?
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.
> 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.
--
Dan Espen E-mail: [EMAIL PROTECTED]
--
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]
