Subject: FVWM: Managing unmanaged windows

From: Neil Bird <[email-masked]>
Date: Wed, 07 Jun 2000 16:50:11 +0100

This isn't really a FVWM question, but I'm hoping that someone on the
FVWM-programming side of things will know the answer.

  I have a couple of override-redirect windows (yes, I know), and in order
to maintain some semblance of control (mainly under FVWM, but also under
Exceed), I'd like to keep the windows, when they're open, one level above
their parents (instead of at the top of the window stack).

  Then, if the parent window is pushed to the back, the popup follows it.

  I suspect I ought to use XRestackWindows, but I only get BadWindow
errors. I think that's something to do with the windows not being
'siblings' (I've not found a useful definition of that), and that, under
FVWM (or any WM) the 'parent' window is really a collection of windows
holding borders and the like (as revealed by xlswins -l).

  Anyone any pointers? I do have /an/ X window-id for the parent and for
the override-redirect window, which I believe correspond to the actual
client windows (underneath all the WM gubbins).

-- 
=====================- http://www.racaldefence.com/ -===================
  Neil Bird                      |
                                 |    If this .signature looks pants,
    mailto:[email-masked]  |     then just stop using Outlook!
--
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: Wed, 07 Jun 2000 17:14:43 +0100

> holding borders and the like (as revealed by xlswins -l).

Sibling window have the same parent. The parent of your
override-redirect window will be the root window and the parent of your
normal client will be an fvwm window so you won't be able to use
XRestack on them both.
> client windows (underneath all the WM gubbins).

Well, you could use XQueryTree() recursively to find the window that is
a child of the root and is an ancestor of your normal client (under fvwm
it is the grandparent of the client, other window managers are
different). You can restack these two but be aware that fvwm may get
confused or it may restack them itself in a different order. i.e. don't
expect this to work for long.

Cheers,
Tim.

---

From: Neil Bird <[email-masked]>
Date: Thu, 08 Jun 2000 09:14:40 +0100

> expect this to work for long.

  That's OK; I really only wanted it to be a one-shot "make sure the
b#gger's moved out of the way" of the window is lowered (ir vice-versa if
the parent's re-raised).

  As it happens (there's a 'yeugh' coming) I'll have to 'keep' doing it
all the time the popup's up (10 times a second) since the GUI builder we
use doesn't notify us of [it's parent] window raise/lowers.

---

From: Neil Bird <[email-masked]>
Date: Fri, 09 Jun 2000 10:45:21 +0100

> expect this to work for long.

  OK, this is, erm, doing something now.

  I'm issuing (once I've found the correct window IDs) an XRestackWindows
on (popup_id,parent_id).

  I'd *expect* this to put the parent window(s) under the popup (not quite
what I want yet - I want to move the popup, but I'll deal with that
later).

  What /actually/ happens is that the (override redirect) popup appears on
top, then I issue the call & the parent window moves from 2nd.-to-top (it
was /on/ top) to the very bottom of the window stack (under EVERYTHING,
not just the popup).

  What on Earth's going on? Is that supposed to happen with a Restack?

---

From: Tim Phipps <[email-masked]>
Date: Fri, 09 Jun 2000 13:24:19 +0100

>   What on Earth's going on? Is that supposed to happen with a Restack?

I haven't the faintest what's going on but have you tried this without a
window manager?

Cheers,
Tim.

---

From: Neil Bird <[email-masked]>
Date: Fri, 09 Jun 2000 13:48:14 +0100

Tim Phipps wrote:
> >   What /actually/ happens is that the (override redirect) popup
> >   appears on top, then I issue the call & the parent window moves from
> >   2nd.-to-top (it was /on/ top) to the very bottom of the window stack
> >   (under EVERYTHING, not just the popup).
>

  I think I got the same thing under Exceed, but I didn't try /no/ WM.

  Anyway, I got what I wanted by using the method I'd tried originally
(albeit with the correct [child of root] window IDs): XConfigureWindow on
the popup, and restack=above-sibling(parent). Works a treat.