Re: problem with 'other-frame' with KDE "Focus Follows Mouse" window behavior

[Alain Cochard]

Alan Mackenzie <acm@muc.de> writes:

> Alain Cochard <alain@geophysik.uni-muenchen.de> wrote on 14 Dec 2005
> 18:47:05 +0100:
> 
> > Hello.
> 
> > I'm using Emacs GNU Emacs 21.4.1 
> >      (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars) 
> >      of 2005-05-18 on decompose.build.redhat.com
> > with KDE 3.4.2-0.fc4.1 Red Hat.
> 
> > When I use the "Focus Follows Mouse" KDE window behavior, then the
> > emacs command 'M-x other frame' does not work.
> 
> How, precisely, does it "not work"?  Could it be that M-x
> other-frame (which has the binding C-x 5 o, by the way) does work,
> but that KDE instantly restores the focus to the frame where the
> mouse is?
> 
> Does it still fail to work when the mouse isn't over any frame?

Thanks for asking for clarification.  I have now experimented a bit. 

(I) If I have on the desktop only 2 frames which do not overlap, and
that I start with the mouse out of either frames (but one of them
still active, i.e., with the cursor inside it), then I would say that
everything works fine.  After the first 'M-x other frame', the cursor
goes to the other frame and the mouse is automatically moved to that
frame, near the top right corner.  If I don't touch the mouse, this is
reproduced for any subsequent 'M-x other-frame'.

(II) Now the case where I have on the desktop only 2 frames which DO
overlap.

(II A) Case where the frames overlap by the top right corner of the
bottom one and the bottom left corner of the top one:

     --------
    |a       |
    |        |
 ------      |
|b     |     |
|      |-----
 ------

I start with the mouse out of either frame, frame (a) in front (i.e.,
frame (b) partly hidden by (a) -- unlike on the "picture" above), and
focus on (b).  On the 1st 'M-x other-frame', the curse goes to frame
(a), frame (b) staying behind.  On the 2nd 'M-x other-frame', the
cursor comes back to frame (b), and frame (b) is raised to the front
(that is, frame (a) is now partly hidden).  On the 3rd 'M-x
other-frame', the cursor goes to frame (a), but frame (a) stays
behind.  Any subsequent 'M-x other-frame' will switch frame, with (b)
staying in front.

If I start with everything the same except that frame (b) is in front,
any number of 'M-x other-frame' will switch frame, with (b) staying in
front.


(II B) Case where the right part of the left frame is totally included
inside the right frame:
      
          ---------
         |a        |
         |         |
 -----------       |
|b          |      |
|           |      |
 -----------       |
         |         |
         |         |
          ---------

If I start with the mouse out of either frames, with the cursor in
frame (b), the behavior is identical to case (II A).

If I start with the mouse out of either frames, with the cursor in
frame (a), with frame (b) in front, on the 1st 'M-x other-frame' the
cursor goes to frame (b) which stays in front; with the 2nd 'M-x
other-frame', the cursor goes back to frame (a), frame (a) being
raised.  Any subsequent 'M-x other-frame' with cause absolutely
nothing!  The cursor stays in frame (a), frame (a) stays in front --
I'm stuck there.

If I start exactly the same as before, except that frame (a) is already
in front, then I'm stuck there right away: any number of 'M-x
other-frame' has no effect.


I tried many times and it looks reproducible, but actually it's not
100% the case. I have bound 'M-x other frame' to 'M-b' so that I can
actually switch frames very fast.  Let's take case (II A).  If I leave
my fingers on 'M-b', then, sure enough, after some seconds during
which I see the very fast switching of frames, I end up to a situation
where the focus is in frame (a), frame (a) is in the front, and I'm
stuck there.  And before getting there I even see a few "blinkings"
which indicate that frame (a) was raised to the front a few times.

Thanks for your time,
Alain

> > I have experimented with the variable focus-follows-mouse set to 't' or
> > 'nil' but I don't see any difference.
> 
> > Other than that, the "Focus Follows Mouse" KDE behavior works
> > properly, so I thought it might be an emacs problem.  (On the other
> > hand, if I try the "Focus _Under_ Mouse" KDE window behavior instead,
> > then 'M-x other-frame' works fine...)
> 
> > Previously I was using Emacs 21.3.1 with KDE 3.1.4-4 and it was
> > working properly.
> 
> > Thanks in advance for any hint.
> > AC