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

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

[Alain Cochard]

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.  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

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

[Katsumi Yamaoka]

>>>>> In <m31x0fvaee.fsf@geophysik.uni-muenchen.de> Alain Cochard wrote:

> 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.  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.

I have a similar problem on Fedora Core 4, using the Gnome
desktop.  Once I sent a report about that to the emacs-devel
list:

http://article.gmane.org/gmane.emacs.devel/39702

The solution I wrote there might not help your problem, though.
The problem is in Emacs built with --with-x-toolkit=lucid (which
is the default).  No problem in the one built with --with-gtk,
but /usr/bin/emacs-21.4 that FC4 provides seems to have been
configured as the default.

Masatake YAMATO who is one of the Emacs developers told me that
he will improve it, although it has not been achieved yet.  I'll
forward this thread to him.

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

[Alan Mackenzie]

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?

> 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

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

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

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

[Katsumi Yamaoka]

>>>>> In <m3acf211ny.fsf@geophysik.uni-muenchen.de> Alain Cochard wrote:

> (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.

It seems to be just the same case as mine.  Doesn't it solve by
the following?

(if (and (not (featurep 'xemacs))
	 window-system)
    (defadvice raise-frame (after make-it-work (&optional frame) activate)
      "Make it work."
      (call-process
       "wmctrl" nil nil nil "-i" "-R"
       (frame-parameter (or frame (selected-frame)) 'outer-window-id))))

Where "wmctrl" is the external command which you can get from:

http://sweb.cz/tripie/utils/wmctrl/

Note that you have to install the "wmctrl" command before
putting the advice into the ~/.emacs file.

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

[Alain Cochard]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> >>>>> In <m3acf211ny.fsf@geophysik.uni-muenchen.de> Alain Cochard wrote:
> 
> > (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.
> 
> It seems to be just the same case as mine.  Doesn't it solve by
> the following?
> 
> (if (and (not (featurep 'xemacs))
> 	 window-system)
>     (defadvice raise-frame (after make-it-work (&optional frame) activate)
>       "Make it work."
>       (call-process
>        "wmctrl" nil nil nil "-i" "-R"
>        (frame-parameter (or frame (selected-frame)) 'outer-window-id))))
> 
> Where "wmctrl" is the external command which you can get from:
> 
> http://sweb.cz/tripie/utils/wmctrl/
> 
> Note that you have to install the "wmctrl" command before
> putting the advice into the ~/.emacs file.


 > >>>>> In <m3acf211ny.fsf@geophysik.uni-muenchen.de> Alain Cochard wrote:
 > 
 > > (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.
 > 
 > It seems to be just the same case as mine.  Doesn't it solve by
 > the following?
 > 
 > (if (and (not (featurep 'xemacs))
 > 	 window-system)
 >     (defadvice raise-frame (after make-it-work (&optional frame) activate)
 >       "Make it work."
 >       (call-process
 >        "wmctrl" nil nil nil "-i" "-R"
 >        (frame-parameter (or frame (selected-frame)) 'outer-window-id))))
 > 
 > Where "wmctrl" is the external command which you can get from:
 > 
 > http://sweb.cz/tripie/utils/wmctrl/
 > 
 > Note that you have to install the "wmctrl" command before
 > putting the advice into the ~/.emacs file.

Yes, I did that and it worked.  

I had some trouble installing wmctrl, though.  The 'configure' stage
reported:
    checking for X... no 
and then the 'make' failed.  As Yamaoka-san said he was on Fedora Core 4,
just like me, I found this strange.  At some point I thought that
installing some KDE development tools (which I hadn't installed) could
solve the problem.  I tried to install them with the KDE 'Add/Remove
Applications (Package Management)' menu.  It failed because something
was not found, which I did not understand.  I then tried to install
some optional package 'kdevelop' (don't know what it is) from the
command line:
    yum install kdevelop 
Then the system installed other packages on which kdevelop depends,
and so on.  

After it was finished, wmctrl compiled fine, so I inserted the small
lisp lines above and it solved the 'M-x other frame' problem.

Thanks a lot.
a.