Subject: FVWM: AutoRaise & Motif Menus

From: [email-masked] (Mark Scott)
Date: Thu, 12 Oct 1995 14:36:49 +0000 (CDT)

I use the AutoRaise feature of FVWM (with a time delay of course....) & have
noticed that very, very often when using Motif applications, if I'm not very
deliberate when dragging down an application pulldown menu, FVWM often raises 
the application main window "in front" of the pulldown menu. The FVWM pull down
menus are always fine. I'm not being two-thumbed when I do this operation
and since I haven't let go of the menu yet, I don't understand why the
main window is getting focus for the autoraise.  I'm running FVWM 2.24 using 
the FvwmAuto module, but I've also seen this behavior back in the 1.24 days 
when autoraise was builtin. Any help would be greatly appreciated.

 _____________________________________________________________________________
| Mark Scott                        | 				             |
| Motorola Computer Group           |  There's no better place on earth,     |
| [email-masked]   	    |   than the road that leads to heaven.  |
| Ph# (217) 384-8536	            |                                        |
| http://www.prairienet.org/~mscott |             Steven Curtis Chapman      |
 -----------------------------------------------------------------------------
--
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: Elan Feingold <[email-masked]>
Date: Thu, 12 Oct 1995 18:42:55 -0400

> when autoraise was builtin. Any help would be greatly appreciated.

Yes!!  I've noticed this too, in these three situations (all with
2.0plXX):

 o Not using FvwmAuto at all.
 o Using FvwmAuto with a small time delay (0).
 o Using FvwmAuto with a large time delay (9999).

So I feel that there's still some internal fvwm code that messing
something up.

Best regards,

-Elan

---

From: Jose M. Pereira <[email-masked]>
Date: Fri, 13 Oct 95 19:16:48 +0100

-----BEGIN PGP SIGNED MESSAGE-----

"MS" == Mark Scott <[email-masked]> writes:

  MS> I use the AutoRaise feature of FVWM (with a time delay of course....) &
  MS> have noticed that very, very often when using Motif applications, if I'm
  MS> not very deliberate when dragging down an application pulldown menu,
  MS> FVWM often raises the application main window "in front" of the pulldown
  MS> menu. The FVWM pull down menus are always fine. I'm not being

If you look at the code of FvwmAuto (which works the same way as the AutoRaise
feature of 1.24), this is what is expected, I'm afraid. "very deliberate when
dragging", in more technical terms, means "change focus to the menu before the
autoraise timeout expires".

A change to FvwmAuto I still have to test is to reset the autoraise timer
whenever a new window is created (that is, FvwmAuto must spy AddWindow
messages).

Meanwhile, you can try this:

- - Put the mouse on the application window containing the menus;
- - Wait that window is raised
- - pull down any menus you like, waiting for the timeout between them!

You may also play w/ the timeout value to find the best value for you.

I'm currently working on a better Autoraise module, to allow for window and
class specific autoraise. Wishes and suggestions welcome!

- -- 
Jose' Pereira
	     INESC (Inst. Eng. Sistemas e Computadores)
             R. Alves Redol 9, 6. 1000 Lisboa, PORTUGAL.
             Phone.: +351 1 3100223 Fax...: +351 1 525843
 e-mail: [email-masked] PGP PUBLIC KEY: finger -m pereira @sabrina.inesc.pt
		<< Hit any user to continue >>

---

From: Elan Feingold <[email-masked]>
Date: Mon, 16 Oct 1995 11:05:31 -0400

> autoraise timeout expires".

I've noticed the problem when I wasn't running FvwmAuto.  Am I just
hallucinating, or is the problem in the core fvwm code?

-Elan

---

From: Paul D. Smith <[email-masked]>
Date: Mon, 16 Oct 95 14:28:40 EDT

%% Regarding Re: FVWM: AutoRaise;
%% "Jose M. Pereira" <[email-masked]> writes:

    jmp> A change to FvwmAuto I still have to test is to reset the
    jmp> autoraise timer whenever a new window is created (that is,
    jmp> FvwmAuto must spy AddWindow messages).

I'd love this.

I don't have too many problems with menus, 'cause I don't use Motif
menus much, but I have many overlapping windows.  Often what will happen
is I'll put a cursor on window A (almost always Emacs) and quickly hit a
key which causes another window B to deiconify under my mouse and now be
selected: I want the new window to be on top.

But FvwmAuto then raises window A when the autoraise timeout expires,
and I have to send it to the background to see window B again.

Another thing that happens which is also annoying is that I'll move my
mouse to the title bar to left-click the top window into the back, but
I'll overshoot briefly onto another window or the root.  Then I move my
mouse back to the top window, which causes the autoraise timer to start,
left-click it to the back.  Then when the autoraise timer goes off, it
comes back to the front.  Sometimes I can get into this rhythm where
I'll keep left-clicking a window into the back and FVWM keeps stubbornly
raising it again for 4 or 5 times! :)

I want autoraise to basically keep track when a new window is selected,
and junk any old autoraise in progress and start a timer for the newly
selected window.  It seems to do this normally (if you move to window A
then back again it doesn't raise window A), but not when windows are
explicitly deiconified or raised.

Does that make sense?  I'd be very willing to alpha- or beta-test any
patches to FvwmAuto you have :)

-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 Senior Software Engineer                                   Bay Networks, Inc.
-----------------------------------------------==<http://www.baynetworks.com/>-
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
     These are my opinions--Bay Networks takes no responsibility for them.
--
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: Jose M. Pereira <[email-masked]>
Date: Mon, 16 Oct 95 20:11:45 +0100

"PDS" == Paul D Smith <[email-masked]> writes:
In article <[email-masked]> Paul D. Smith
<[email-masked]> writes:

  PDS> Another thing that happens which is also annoying is that I'll move my
  PDS> mouse to the title bar to left-click the top window into the back, but
  PDS> I'll overshoot briefly onto another window or the root. Then I move my
  PDS> mouse back to the top window, which causes the autoraise timer to
  PDS> start, left-click it to the back. Then when the autoraise timer goes
  PDS> off, it comes back to the front. Sometimes I can get into this rhythm
  PDS> where I'll keep left-clicking a window into the back and FVWM keeps
  PDS> stubbornly raising it again for 4 or 5 times! :)

That's why I find the "default" 500ms timeout a bit tight. 750-1000 is more
like it (and more than that is too sluggish).

  PDS> I want autoraise to basically keep track when a new window is selected,
  PDS> and junk any old autoraise in progress and start a timer for the newly
  PDS> selected window. It seems to do this normally (if you move to window A
  PDS> then back again it doesn't raise window A), but not when windows are
  PDS> explicitly deiconified or raised.

Hmm. Yes, that's how it works (should work). I'm sure there is a catch mixing
deiconify/raise/focus/whatever events, but the most common trouble is the
timing. Unix/X is not real-time, you know... A thorough check of all event
timestamps (possible in 2.0!) is REALLY complicated.

  PDS> Does that make sense? I'd be very willing to alpha- or beta-test any
  PDS> patches to FvwmAuto you have :)

Welllll... The prototype I have is not a patch, but a *new* module, written in
Python. Of course, after getting things right, the algorithm can go to a
C module as a patch... If I have the time ;-)

(BTW, that module now correctly emulates/substitutes FvwmAuto, FvwmAudio,
FvwmClean (the "famous" AutoLower module!), and, basically, any
non-X-interface module. Latest version works w/ 2.0 (I switched last week,
finally) and can use Python's tkinter -- that is, Tk widgets...)

---

From: Paul D. Smith <[email-masked]>
Date: Mon, 16 Oct 95 15:30:35 EDT

%% Regarding Re: FVWM: AutoRaise;
%% Jose M. Pereira <[email-masked]> writes:

    jmp> That's why I find the "default" 500ms timeout a bit
    jmp> tight. 750-1000 is more like it (and more than that is too
    jmp> sluggish).

OK, I'll try that.

    jmp> Hmm. Yes, that's how it works (should work). I'm sure there is
    jmp> a catch mixing deiconify/raise/focus/whatever events, but the
    jmp> most common trouble is the timing. Unix/X is not real-time, you
    jmp> know... A thorough check of all event timestamps (possible in
    jmp> 2.0!) is REALLY complicated.

Ah.  I didn't think of that.  Well, humph.  I wonder if there's a simple
way to absolutely verify that it's a delivery time/order from the server
problem vs. some kind of bug in the FvwmAuto code?

    jmp> Welllll... The prototype I have is not a patch, but a *new*
    jmp> module, written in Python.

Uh, never mind :)