Subject: FVWM: Rotate window list without changing focus?

From: "Jan T. Kim" <[email-masked]>
Date: Fri, 10 Mar 2000 21:21:57 +0100

Hi all,

here's a quick question: Is it possible to raise a window and rotate it
to the top of the windowlist without having to give that window the
keyboard focus?

Below follows a description of what I want, and what I've tried so
far. Please tell me what I overlooked...

I would like to set up fvwm2 such that I can cyclically raise all
windows with the PageUp / PageDown keys, i.e. repeated PageDown
keystrokes should raise one window after the other, allowing me to find
a window which I've buried too deep. I use MouseFocus, and I'd like to
be able to move the mouse pointer over the root window, and then start
cycling, so no application will receive these keystrokes, and I won't
have to snatch the PageDown keystrokes away from an application which
may have a use for it.

The most simple approach

    Key Next         R         N     Next [*] Raise

does not work, because the raised window does not become current, so
repeated PageDown keystrokes will just raise the same window again,
i.e. effectively do nothing.

It seems that the only command for rotating the windowlist is Focus,
so I tried:

    Key Next         R         N     Function Next-Focus-and-Raise

    AddToFunc Next-Focus-and-Raise  "I" Next [*] Raise
    +                               "I" Next [*] Focus

This works once, but not repeatedly. Somewhat weirdly, the the Focus
command gives the keyboard focus to the target window, even though
this is inconsistent with MouseFocus if the mouse pointer is over the
root window. As a result, all but the first PageDown keypresses are
sent to the application owning the target window instead of being
processed by fvwm2.

A while ago, I have settled for

    Key Next         A        CM     Function Next-Focus-and-Raise

However, I am not satisfied with this solution, because (1) I don't
like having the window manager taking away keypresses from applications
which do have the keyboard focus and (2) I find pressing
Ctrl-Alt-PageDown quite inconvenient, so I don't use this as often as I
might do otherwise.

Thanx in advance for any hints.

Greetinx, Jan
-- 
 +- Jan T. Kim -------------------------------------------------------+
 |             email: [email-masked]                           |
 |             WWW:   http://www.mpiz-koeln.mpg.de/~kim/              |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Tim Phipps <[email-masked]>
Date: Tue, 14 Mar 2000 14:22:57 +0000

> to the top of the windowlist without having to give that window the

No.  The windowlist is always headed by the window that has focus and is
used as the starting point for next/prev commands in functions.
> root window.

The focus command has to work no matter what focus style is used or it
would be useless.  MouseFocus just means that an implicit focus command
is run every time the mouse enters a window. ClickToFocus does the focus
command when the mouse is clicked on a window.

> As a result, all but the first PageDown keypresses are

Correct. The key binding is for the root context only, it means it is
active when no window has the focus, it doesn't mean active when the
mouse is in the root window.  If you want that you could bind a mouse
button:

Mouse 1 R N Function Next-Focus-and-Raise

> Ctrl-Alt-PageDown quite inconvenient, so I don't use this as often as I

A solution for (2) is to use a more convenient key binding. I use KP_Add
and KP_Subtract.  I haven't found a program yet thatneed these and can't
use the normal plus/minus keys.

(1) is difficult.  As you have found you can't have keyboard driven
circulation without moving the focus, therefore you have to take those
keys away from applications.

Cheers,
Tim.

---

From: "Jan T. Kim" <[email-masked]>
Date: Tue, 14 Mar 2000 16:24:28 +0100

> used as the starting point for next/prev commands in functions.

Ok. Does this imply that the root window is in the window list, and is
just skipped by the Next and Prev commands?

> command when the mouse is clicked on a window.

This means that fvwm's focus policies are built on top of the functionality
that is accessible with the Focus command? Thanks for this info. If I
understood this correctly, then the question would become: Is there a
command which I could use to reclaim the focus for the root window? E.g.
could I simulate a mouseclick at the current position? Or is there some
generic name or classname for the root window, that I could append a line
like

    +                               "I" Next [Root] Focus

to the Next-Focus-and-Raise function shown above?

> mouse is in the root window.  If you want that you could bind a mouse

Ok, but all three mouse buttons are used for popup menus. It's true,
though, that I don't use them that frequently. Furthermore, now that I
think of it, I like the idea of using the mouse instead of the keyboard
as I have to move the mouse onto a patch of root window anyway. Thanks
for pointing this out.

> use the normal plus/minus keys.

This is a matter of habits, I guess -- xcalc is perfectly happy with the
normal plus and minus keys, but personally, I find it more convenient to
use the keypad with xcalc...

> keys away from applications.

An alternative might be to take the focus away from the applications
after briefly giving it to them (as already mentioned above).

Greetinx, Jan

---

From: Tim Phipps <[email-masked]>
Date: Tue, 14 Mar 2000 17:34:38 +0000

> just skipped by the Next and Prev commands?

No, 'fraid not, the windowlist is the list of windows that fvwm is
managing i.e. the windows that fvwm can move/iconify/resize etc..

> to the Next-Focus-and-Raise function shown above?

I don't know of a way to do this.  I don't think sending a mouse click
to the root is the way to go as you have already bound some menus to all
the mouse buttons. What is needed is an UnFocus command. I tried a quick
hack program to send an EnterNotify event to fvwm and fvwm gets the
message but fails to move the focus. I'm not sure why it fails, here's
the program:

#include <X11/Xlib.h>

main()
{
  Display *dpy;
  int scr;
  Window root;
  XEvent event;

  dpy = XOpenDisplay(NULL);
  scr = DefaultScreen(dpy);
  root = DefaultRootWindow(dpy);
  event.xcrossing.type = EnterNotify;
  event.xcrossing.display = dpy;
  event.xcrossing.window = root;
  event.xcrossing.root = root;
  event.xcrossing.subwindow = None;
  event.xcrossing.focus = True;
  XSendEvent(dpy, root, False, EnterWindowMask, &event);
  XCloseDisplay(dpy);
}

Cheers,
Tim.