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

From: Gregg Dameron <gregg.dameron_at_lmco.com>
Date: Fri, 30 Aug 2002 11:38:20 -0600

Mikhael Goikhman wrote:

> On 27 Aug 2002 10:12:49 -0600, Gregg Dameron wrote:
> >
> > 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?
>
> The add_window event should do it. Please provide the config that traps
> 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


--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Fri Aug 30 2002 - 12:38:15 BST

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