Subject: FVWM: WindowList

From: Christopher Wolf <[email-masked]>
Date: Mon, 18 Aug 1997 18:53:57 -0500 (CDT)

As I begin to get carpel tunnel from switching between the mouse and
keyboard, I begin to start trying to do as much as possible from the
keyboard, which is situated correctly.

I find that the WindowList action, when initiated from the keyboard,
and in the situation where the window is also chosen using the
keyboard, that the window chosen is not focused correctly.

A search of the archives yeilds the message
<[email-masked]> and it's followup, in which
this is mentioned, and Chuck mentions it is a known bug.

Has anyone found the solution to this bug yet?  I'd hate having to
debug it myself, since I need to debug from another terminal across
the hall, not having a dumb terminal connected to my workstation.

-W

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "T. Piepho" <[email-masked]>
Date: Mon, 18 Aug 1997 17:48:10 -0700 (PDT)

> the hall, not having a dumb terminal connected to my workstation.

Are you using pointer focus?  This is probably a problem I had, where
selecting a window from the win list wouldn't give it focus. 

fvwm does in fact give the window focus.  It then takes the focus away
because the pointer isn't in the window.  Make sense?  Anyway, I made a patch
that warps the pointer to the window so it will keep focus.  I use it so I can
switch windows with the keyboard using WindowList (bound to compose).  I don't
know if this is best solution because pointer warping is generally considered
evil, but it works for me.

I don't know why you need a dumb terminal to debug fvwm.  I don't have one.
I just have a menu option to restart to an xterm, which I can then start
the fvwm I've compiled from.  Any debugging messages fvwm prints then go
to the xterm.

---

From: Christopher Wolf <[email-masked]>
Date: Tue, 19 Aug 1997 00:28:25 -0500 (CDT)

On Mon, 18 Aug 1997, T. Piepho wrote:

#> On Mon, 18 Aug 1997, Christopher Wolf wrote:
#> > I find that the WindowList action, when initiated from the keyboard,
#> > and in the situation where the window is also chosen using the
#> > keyboard, that the window chosen is not focused correctly.
#> > 
#> Are you using pointer focus?  This is probably a problem I had, where
#> selecting a window from the win list wouldn't give it focus. 

I use the default MouseFocus, which is what I assume you mean by
pointer focus.

#> fvwm does in fact give the window focus.  It then takes the focus away
#> because the pointer isn't in the window.  Make sense?  Anyway, I made a patch
#> that warps the pointer to the window so it will keep focus.  I use it so I ca
#> switch windows with the keyboard using WindowList (bound to compose).  I don'
#> know if this is best solution because pointer warping is generally considered
#> evil, but it works for me.

Well the default WindowList action is to warp to the window after
Focusing and Raising the window, but it does not seem to be happening
correctly.  I do see the same thing you see -- that it does get the
focus for a while -- and I was trying to debug to see if the problem
was the menu code trying to put the mouse/focus back (somewhere) when
it was done or maybe something just not executing, but - alas - the
network went down right as I closed in on it.

Anyone have any info?

#> I don't know why you need a dumb terminal to debug fvwm.  I don't have one.
#> I just have a menu option to restart to an xterm, which I can then start
#> the fvwm I've compiled from.  Any debugging messages fvwm prints then go
#> to the xterm.

When I say debug, I mean line by line with a debugger through the
appropriate regions.  And if that region is something like do_menu,
where the focus is moved for a short time to pop up the menu, then I
lose focus on my gdb debugging window when the routine moves the focus
to the menu, pretty much killing the whole deal right there.  Can't
type (no focus!), can't refocus (no window manager!).  Need a dumb
terminal to allow things to work right.

I've heard one can "nest" window managers somehow to allow debugging
of one of them while the other kicks in to allow you to continue to
move about, but could not find info on it.  Anyone have some info on
how it's done by the pro's?

-W

---

From: [email-masked] (Paul D. Smith)
Date: 19 Aug 1997 09:52:21 -0400

%% Christopher Wolf <[email-masked]> writes:

  cw> I've heard one can "nest" window managers somehow to allow debugging
  cw> of one of them while the other kicks in to allow you to continue to
  cw> move about, but could not find info on it.  Anyone have some info on
  cw> how it's done by the pro's?

This is what I do, and it's totally trivial... if you have the right
version of X :)

The newer X's (I think starting with X11R6 or X11R6.1) come with a
"nexting X server", called Xnest.  Look for it in your /usr/bin/X11.
If you don't have it, you'll need a new version of X11.

Check the man page, but you simply start it and tell it to display on
your real X server; it opens a window inside of which is a whole X
screen.  It creates a new display you can use with fvwm or whatever,
like "fvwm2 -display :1".

There may be other ways, but this is _far_ and away the simplest.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
     These are my opinions--Bay Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "T. Piepho" <[email-masked]>
Date: Tue, 19 Aug 1997 10:41:49 -0700 (PDT)

> correctly.  I do see the same thing you see -- that it does get the

Are you sure?  The code is do_windowList in windows.c.  It seems that the
stock action is to to call RAISE_IT on the window, which doesn't warp the
pointer.  This is in fvwm 2.0.43, I haven't upgraded for a while.  I think
I added code so it would warp to the window if you were using pointer focus,
but I can't quite remember what I did exactly.  When I get home from work
today I'll check my code.

---

From: Christopher Wolf <[email-masked]>
Date: Tue, 19 Aug 1997 12:50:56 -0500 (CDT)

On Tue, 19 Aug 1997, T. Piepho wrote:

#> > Well the default WindowList action is to warp to the window after
#> > Focusing and Raising the window, but it does not seem to be happening
#> > correctly.  I do see the same thing you see -- that it does get the
#> 
#> Are you sure?  The code is do_windowList in windows.c.  It seems that the
#> stock action is to to call RAISE_IT on the window, which doesn't warp the
#> pointer.  This is in fvwm 2.0.43, I haven't upgraded for a while.  I think
#> I added code so it would warp to the window if you were using pointer focus,
#> but I can't quite remember what I did exactly.  When I get home from work
#> today I'll check my code.

It must have changed.  While the code is in do_windowlist, once it
returns it executes WindowListFunc (windowlistfunc) on the window.
>From the 2.0.45 manpage:

     WindowList [options]
          Generates a pop-up menu (and pops it up) in  which  the
          title  and geometry of each of the windows currently on
          the desk top are shown.  The geometry of iconified win-
          dows  is  shown in parenthesis.  Selecting an item from
          the window list pop-up menu will by default  cause  the
          interpreted  function WindowListFunc to be run with the
          window id of that window passed in as $0.   By  default
          the WindowListFunc looks like this:
 
               AddToFunc WindowListFunc "I" WindowId $0 Iconify -1
               +                        "I" WindowId $0 Focus
               +                        "I" WindowId $0 Raise
               +                        "I" WindowId $0 WarpToWindow 5p 5p
 
          You can Destroy the builtin WindowListFunc  and  create
          your own if these defaults do not suit you.
	  ...

In tracing the action, I did see these occur in this order (up to the
warp, when the network went to dinner).

-W