FVWM: Mapped windows going to top

From: Allen Brady Montz <bradym_at_cs.arizona.edu>
Date: 10 Dec 1996 17:07:54 -0700

I'm wanting to fix some FvwmIconMan behavior that's always bugged me. When a
manager window doesn't have any windows to manage, it unmaps itself. When it
gets windows, it then maps itself. When that happens, the manager window gets
raised to the top of the window stack. In my personal setup I have one manager
window devoted to emacs windows, and if I switch from a page with emacses to
one without, and then back, my FvwmIconMan window typically is sitting on top
of one of my emacs windows.

Before this degenerates further into vagueness, here's an example:

On page 1, I have an emacs window sitting on top of my FvwmIconMan window
On page 2, I have nothing

Switching from pages 1 -> 2, my FvwmIconMan disappears.
Switching from pages 2 -> 1, my FvwmIconMan reappears and is on top.

Since my FvwmIconMan windows are sticky, things work more nicely when my
window doesn't have to unmap itself. Another example:

Page 1: emacs window and an FvwmIconMan window
Page 2: some xterms.
In this case, I have one FvwmIconMan window managing everything, so when
I switch from 1 -> 2, my FvwmIconMan window doesn't unmap/map itself, since
on both pages it's managing > 0 windows. Now, what's mega cool is that suppose
on page 1, my FvwmIconMan is beneath an emacs window, and on page 2, it's on
top of an xterm. If I flip back and forth between the two, everything stays
just the way it should.

So, I guess what I want is that when a window gets unmapped, that it not
"lose" it's place in the window stack. How should I achieve this? (Either
making a change to fvwm, neato X tricks, or "read the damn manpage" are
perfectly accceptable).

-- 
 Brady Montz
 bradym_at_cs.arizona.edu
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue Dec 10 1996 - 18:07:50 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:59 BST