Subject: Tricks to using xnest?

From: Dan Espen <[email-masked]>
Date: Fri, 06 Dec 2002 13:00:29 -0500

Dominik Vogt <[email-masked]> writes:
> You can run a separate X server or an Xnest in a window.
...
> To run fvwm in an Xnest window (Xnest should run on any X server):
> 
>   $ Xnest -full -sync -name "Xnest :3" -fp `xset -q | grep fonts` :3         
>    
>   $ fvwm2 -d :3 ...
> 
> Both ways have their disadvantages.  With a separate X server,
> XFree frequently hangs when switching displays, especially if the
> pointer/keyboard/server is grabbed.  Xnest does not handle all
> types of events well.  It's especially annoying that you can't
> easily leave the Xnest window without moving the pointer across
> it.  You could use the WarpPointer command for that.  Also, key
> bindings don't work in an Xnest window if they are already handled
> by the parent fvwm.  Furthermore it is sometimes difficult to
> attach a debugger to an fvwm running under Xnest.

I've installed xnest, and attaching gdb to an fvwm inside of xnest
is no problem.

I was trying to get this working to see if I could contribute
to the Openinterface problem, but right now, I'm afraid I don't
know what part of Fvwm to set a breakpoint in.  I tried fvwm/events.c
HandleEvents, but that seems to be driven too often.

Does anyone have any hints?

-- 
Dan Espen                           E-mail: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 6 Dec 2002 19:14:36 +0100

> HandleEvents, but that seems to be driven too often.

(Assuming the problem was with windows closing unexpectedly, I
can't remember exactly right now).

Start with destroy_window() (add_window.c) and see from where and
why is it being called.  Hopefully it's not from an event in
events.c.  Try to figure out why it is being called.  It may help
to add a debug fprintf right before any destroy_window call to
narrow down the reason.  You want to find out if the application
withdrew its window or if fvwm destroys it on its own.  In the
former case, we have to pin down the root cause why the
application thinks it must unmap its window.

Bye

Dominik ^_^  ^_^