Subject: FVWM: New vs.moved window in FvwmEvent?

From: Gregg Dameron <[email-masked]>
Date: Tue, 27 Aug 2002 10:12:49 -0600

Running 2.4.7 on Solaris.

I would like to conditionally override any window's position when it
first appears, to bring into full view any window that comes up "too
low" (i.e., partially obscured by the Task Bar, which I have on
Layer 6).  ManualPlacement is not an option in this case.

FvwmEvent sees both new and user-moved windows as a
"configure_window" event.  (I trapped for, but never saw, an
"add_window" event.)  "PlacedByFvwm" is false on a new window if the
app has its own ideas about position.  Is there another
discriminator I can use?

Gregg Dameron

--
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: Mikhael Goikhman <[email-masked]>
Date: Tue, 27 Aug 2002 20:50:52 +0000

> app has its own ideas about position.  Is there another

The add_window event should do it. Please provide the config that traps
this event and does not work for you.

Regards,
Mikhael.

---

From: Gregg Dameron <[email-masked]>
Date: Fri, 30 Aug 2002 11:38:20 -0600

> this event and does not work for you.

I see the problem now.  To prevent overwhelming the complex function that
I use for Cmd (which has a couple of PipeReads in it), I put "Delay 1" in
my configuration.  Without the Delay, a new window generates both
"add_window" and "configure_window" events.  With the Delay,
"configure_window" always arrives first, so the "add_window" never
appears.  Is this expected?

I need to handle new and user-moved windows with different complex
functions.  I suppose I could set up two separate FvwmEvent instances to
trap each of the two events.  Is there a more CPU-efficient approach?

Gregg Dameron