Subject: FVWM: Selected menus disappear?

From: Thomas Voss <[email-masked]>
Date: Tue, 02 Sep 1997 16:57:57 +0200

Dear fans and users of fvwm,

I often remark following behaviour of fvwm2:
When clicking on the menu bar of an application, the pull-down menu
appears for a tenth of a second or so, and afterwards disappears 
directly. No, it does not disappear in reality - as one can see if
the application window is very small and the pull-down menu is very 
big (bigger than the window), the pull-down menu appears *behind* the
application's window!

This appears to happen with almost any application I use.
What can I do to prevent this?

I use fvwm-2.0.45.

Ciao, Thomas
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Merlin Hansen <[email-masked]>
Date: Tue, 2 Sep 1997 09:16:06 -0600 (CST)

> big (bigger than the window), the pull-down menu appears *behind* the

Hi,  I noticed this also and did a little experimenting to come up with a
theory...

Do you run autoraise?  I do.  I believe what is happening in my case is
that I mouse to a new window and hit a button.  The pull-pull down menu
appears, then the auto-raise timer expires and raises the main window above
(infront) of the pull-down menu.  

How do I support this theory... if I click anywhere in the main window that
cancels the button then hit the button again the pull-down appears and
stays there.  

My solution : with my autoraise set to .5 seconds I usually wait out the
timer whenever I switch windows before hitting a button.

Do you notice the same pattern as I do (menu never disappears if main
window has focus for longer than autoraise timer)?

Merlin
-- 
| Develcon Electronics    | E-mail   : [email-masked]        |
| 856-51 St. E, Saskatoon,| Web Site : http://www.develcon.com           |
| Saskatchewan, Canada.   | DISCLAIMER : These are my opinions & views,  |
| S7K 5C7                 | NOT necessarily those of my employers.       |
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Richard Lister <[email-masked]>
Date: Tue, 02 Sep 1997 11:25:54 -0400

On Tue, 2 Sep 1997 09:16:06 -0600 (CST)
Merlin Hansen <[email-masked]> 
> window has focus for longer than autoraise timer)?

You're correct.

This definitely occurs as a result of using FvwmAuto with a reasonably
large timeout. I've been experimenting with this as a result of the
same problem occuring with the Pager balloons. The only solution so far
is to keep the FvwmAuto timeout small (order of 100 msec), or wait a bit
longer before pulling down a menu immediately after entering the window.

Ric

Richard J Lister, Georgetown Institute for Cognitive and Computational Sciences
Georgetown University Medical Center, Washington, DC 20007, USA
Phone: +1 202-687 2878
Email: [email-masked] 
Web: http://www.giccs.georgetown.edu/~ric/
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Michael Tiefenback <[email-masked]>
Date: Tue, 2 Sep 1997 11:49:25 -0400 (EDT)

There is another class of window-popped_up-over-the-menu problem with some
Motif processes.  Whether by Motif programming error or some poor design
interaction (it works successfully for the mwm, but not fvwm), menus
invoked by clicking on the body of windows (not pulldown menu bars!) pops
up the requested menu, but this is immediately followed by a window raise
event.  I thought I might be able to do an explicit raise on the window
and then pop up the menu successfully, but this is not the case.  After
the menu arrives, the parent window is raised and covers it.  Placement
variations by invoking the menu near the sides of the main window allow
one to see the little popup poking its nose or foot from under the main
window.  I don't know why mwm knows to avoid this and fvwm doesn't.  In
all probability, there is an explicit window raise called from the
application by the mouse click.  If it were invoked before the menu, it
would be OK, but mwm doesn't obscure the menu.  This is similar to the
behavior mentioned in this thread.  Apparently fvwm is perfectly willing
to cover up a popup menu, while mwm somehow prevents it.  

What property is mwm respecting, and it one which fvwm can/should be made
to listen to?

Michael Tiefenback