On Tue, Mar 18, 2003 at 05:50:04PM -0500, Bob Woodside wrote:
> On Tue, 18 Mar 2003 14:50:09 -0500
> kutek_at_cybercomm.net wrote:
>
> > situation: pointer determines window focus is on ( window that pointer
> > touches rises to top), there are 2 windows that overlap on the screen.
> >
> > problem: if the pointer sits in the area of overlap, neither window
> > achieves focus...instead each window keeps alternating to the top.
>
> Weird...in over 8 years of using FVWM I've never seen this. What
> timeout value do you use for FvwmAuto?
>
> I was able to duplicate this, but it wasn't easy, and I can't make it
> happen on every try (but that could be due to my own clumsiness). I had
> to set a *very* low timeout value for FvwmAuto (10 ms), place the mouse
> cursor over the top window, then move it very quickly from the top
> overlapping window into a non-overlapped area of the lower window, then
> back again into the top window in the overlapped area. In other words,
> the cursor stayed over the lower window just long enough to satisfy the
> FvwmAuto timeout, but moved back to the other window before the lower
> one could be raised. Once the focus - raise - focus sequence lags
> behind, it becomes a never-ending sequence till you move the pointer out
> of the overlapped area. But without this little trick to start the
> process, nothing out of the ordinary happens with overlapping windows.
>
>
> > moving the pointer to a non overlapping region of either window brings
> > it to the top and is stable, however it seems to me that whatever
> > handles this should know which window is in focus and should not
> > attempt to raise the window below it once the first window is raised.
>
> But FvwmAuto *does* know which window has focus, from its point of
> view. Unfortunately it has no way to know that there's a pending raise
> that hasn't happened yet, so it requests a raise for the window that
> just satisfied the timeout. I don't think there's much that can be done
> about that.
>
> I would suggest trying a higher value for the FvwmAuto timeout and see
> whether this improves the situation.
>
>
> > this becomes a real headache during,for example, web browsing, when
> > message or input boxes appear...and refuse to stay on top.
>
> Is this primarily when this happens? And do you get a couple of
> overlapping message/input boxes popping up at the same time, possibly
> under the pointer so that this gets triggered automagically without your
> having to do anything to start it? As I said, I had to work at it to
> make it happen.
Actually, it's an old hat. If the connection between fvwm and the
X server is much slower than between fvwm and FvwmAuto, it becomes
very likely to happen. I have committed two patches:
1) FvwmAuto 0 is not valid anymore. The minimum value is 1.
This should reduce the probability of a race condition a bit.
2) FvwmAuto sends an "XSync" to fvwm after each action. This
should effectively remove the race with the default FvwmAuto
config.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
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 Tue Mar 18 2003 - 19:11:36 GMT