On Fri, Aug 30, 2002 at 11:38:20AM -0600, Gregg Dameron wrote: > 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? Not really, but nobody ever noticed. The window size gets configured first before the add_window message is sent. > 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? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
