Claude Lecommandeur wrote

>      Doesn't TransientOnTop fit the bill ?

I didn't know this option before. I read the man page up and down but my 
English was not good enough to understand that those Save-as or print popups 
are "transient windows" :-( Thanks for the hint!

Anyway, it doesn't fully work with this option either, but it helped me
identify the problem in more detail: AlwaysOnTop is the culprit.
I have 
  AlwaysOnTop { "xdaliclock"  }

in my .ctwmrc. Now when xdaliclock is running, new transient windows
might come up on top or behind its parent. It seems to be random where
it shows up.

When I remove the AlwaysOnTop option or kill the running xdaliclock,
transient windows always are created on top of their parents (and all
other windows). Restarting xdaliclock makes the transients show up
behind other windows again.

The xdaliclock is of size 40x20 px in the right upper corner, so it
doesn't overlay any of the windows (parents or transients) in question.
Thus, the sole existence of such a program with the AlwaysOnTop option
confuses ctwm.

I looked into the code but don't understand much. With some debugging
output I could figure out this:

1) when AlwaysOnTop is not defined, ctwm calls PlaceOnTop which calls 
  PlaceTransients and the print dialog comes on top.

2) when AlwaysOnTop is defined and xdaliclock is running, PlaceOnTop
  is not executed, only PlaceTransients is called from some other place. 
  The print dialog is behind the parent (Acroread or MozillaThunderbird e.g.)

3) when AlwaysOnTop is defined, but xdaliclock is not running, PlaceOnTop
  is not called, onlt PlaceTransients. The print dialog is behind.

4) In the PlaceTransients function, the code which evaluates TransientOnTop, 
i.e.
    if (sc < ((sp * Scr->TransientOnTop) / 100)) {
  is never executed, not in 1) or 2) or 3). I think this is the only place 
  in the ctwm code where TransientOnTop is considered, so it seems to be
  fully ignored in my settings.


I will try to investigate further, but maybe this does already help someone
else identify the problem.

cu,
Frank




-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Reply via email to