[Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Kim F. Storm]

Jason,

Can you explain why you added that specific line.

I can see that it looks like a reasonable thing to do,
but Chong has problems with it (I don't).

What problem was it supposed to fix?


> From: Chong Yidong <cyd@stupidchicken.com>
>  
> The bug goes away if I remove the indicated line in
> note_mouse_movement, in xterm.c.
>  
>     /* Has the mouse moved off the glyph it was on at the last sighting?  */
>     if (event->x < last_mouse_glyph.x
>            || event->x >= last_mouse_glyph.x + last_mouse_glyph.width
>            || event->y < last_mouse_glyph.y
>            || event->y >= last_mouse_glyph.y + last_mouse_glyph.height)
>       {
>         frame->mouse_moved = 1;
>         last_mouse_scroll_bar = Qnil;
>         note_mouse_highlight (frame, event->x, event->y);
>         /* Remember which glyph we're now on.  */
>         remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         return 1;
>       }
>  
>     return 0;
>   }
>  
> The call to remember_mouse_glyph was not there in earlier versions of
> xterm.c.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Jason Rumney]

storm@cua.dk (Kim F. Storm) writes:

> Jason,
>
> Can you explain why you added that specific line.
>
> I can see that it looks like a reasonable thing to do,
> but Chong has problems with it (I don't).
>
> What problem was it supposed to fix?

Mouse movement is not correctly tracked without it unless track-mouse
is used from lisp (the C code uses last_mouse_glyph for other reasons).

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> Jason,
>>
>> Can you explain why you added that specific line.
>>
>> I can see that it looks like a reasonable thing to do,
>> but Chong has problems with it (I don't).
>>
>> What problem was it supposed to fix?
>
> Mouse movement is not correctly tracked without it unless track-mouse
> is used from lisp (the C code uses last_mouse_glyph for other reasons).

IIUC, the problem was this:

note_mouse_movement is used to handle mouse movement event when
track-mouse is not active, but last_mouse_glyph is only updated when
track-mouse is active.

So it was wrong (or at least stupid) for note_mouse_movement to test
on last_mouse_glyph which would have an arbitrary value based on where
you clicked/dragged the mouse the last time.

Chong, perhaps you can try to understand why you have problems with
mouse clicks due to this change.  I don't have the reported problem,
so I cannot debug it.

Do you have some hacks in mouse.el which may cause problems?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Chong Yidong]

> Chong, perhaps you can try to understand why you have problems with
> mouse clicks due to this change.  I don't have the reported problem,
> so I cannot debug it.

It seems to be related to a setting in KDE's window manager, "Click
Raise Active Window". The tooltip for this setting says:

  When this option is enabled, the active window will be brought to
  the front when you click somewhere into the window contents.

When "Click Raise Active Window" is enabled, the bug appears (clicking
on a toolbar button when the tooltip is active dismisses the tooltip,
but doesn't click the button).  The bug goes away if "Click Raise
Active Window" is disabled.

This is KDE 3.4.3, the one that comes with the Ubuntu "Breezy Badger"
release.

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Chong, perhaps you can try to understand why you have problems with
>> mouse clicks due to this change.  I don't have the reported problem,
>> so I cannot debug it.
>
> It seems to be related to a setting in KDE's window manager, "Click
> Raise Active Window". The tooltip for this setting says:
>
>   When this option is enabled, the active window will be brought to
>   the front when you click somewhere into the window contents.
>
> When "Click Raise Active Window" is enabled, the bug appears (clicking
> on a toolbar button when the tooltip is active dismisses the tooltip,
> but doesn't click the button).  The bug goes away if "Click Raise
> Active Window" is disabled.
>
> This is KDE 3.4.3, the one that comes with the Ubuntu "Breezy Badger"
> release.

Interesting (but I still don't understand where the problem is, or
what triggers it).

What is your setting of x-mouse-click-focus-ignore-position ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 1025 bytes --]

Kim F. Storm wrote:

>>It seems to be related to a setting in KDE's window manager, "Click
>>Raise Active Window". The tooltip for this setting says:
>>
>>  When this option is enabled, the active window will be brought to
>>  the front when you click somewhere into the window contents.
>>
>>When "Click Raise Active Window" is enabled, the bug appears (clicking
>>on a toolbar button when the tooltip is active dismisses the tooltip,
>>but doesn't click the button).  The bug goes away if "Click Raise
>>Active Window" is disabled.
>>
>>This is KDE 3.4.3, the one that comes with the Ubuntu "Breezy Badger"
>>release.
>>    
>>
>
>Interesting (but I still don't understand where the problem is, or
>what triggers it).
>  
>
What happens to last_mouse_glyph when you click on the toolbar? In a GTK 
build (where the toolbar is a GTK widget) and in a non-GTK build (where 
the toolbar is part of the Emacs frame's client area).

Do we still have a bug in the (virtual) glyph used for mouse tracking in 
one of these cases?



[-- Attachment #1.2: Type: text/html, Size: 1418 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[David PONCE]

Hi,

> It seems to be related to a setting in KDE's window manager, "Click
> Raise Active Window". The tooltip for this setting says:
> 
>   When this option is enabled, the active window will be brought to
>   the front when you click somewhere into the window contents.
> 
> When "Click Raise Active Window" is enabled, the bug appears (clicking
> on a toolbar button when the tooltip is active dismisses the tooltip,
> but doesn't click the button).  The bug goes away if "Click Raise
> Active Window" is disabled.
> 
> This is KDE 3.4.3, the one that comes with the Ubuntu "Breezy Badger"
> release.

It works for me with KDE 3.4.3 on Fedora Core 3. I checked that "Click
Raise Active Window" is enabled. My Emacs is built --with-gtk.

Hope it will help.
David

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Chong Yidong]

David PONCE <david.ponce@wanadoo.fr> writes:

> It works for me with KDE 3.4.3 on Fedora Core 3. I checked that "Click
> Raise Active Window" is enabled. My Emacs is built --with-gtk.

Could you try building without gtk, and see if you can reproduce the
problem?

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Chong Yidong]

>     It seems to be related to a setting in KDE's window manager, "Click
> Raise Active Window".
>
> Interesting (but I still don't understand where the problem is, or
> what triggers it).
>   
>
> What happens to last_mouse_glyph when you click on the toolbar? In a
> GTK build (where the toolbar is a GTK widget) and in a non-GTK build
> (where the toolbar is part of the Emacs frame's client area).
>
> Do we still have a bug in the (virtual) glyph used for mouse tracking
> in one of these cases?

I think Emacs doesn't register the click at all.  When I do `C-h k',
and click on the toolbar button (after waiting for the tooltip to pop
up), nothing happens.  I think the window manager is eating the click
event.  Since Emacs tooltips are actual frames (X windows), my guess
is that the window manager is trying to "raise" the tooltip.

Why the recent changes would unearth this problem, I am still trying
to find out.

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[David PONCE]

Hi,

>>It works for me with KDE 3.4.3 on Fedora Core 3. I checked that "Click
>>Raise Active Window" is enabled. My Emacs is built --with-gtk.
> 
> Could you try building without gtk, and see if you can reproduce the
> problem?

Sorry for the delay.  I rebuilt Emacs without GTK, and confirm that
the bug is present.  When a tool tip is displayed, a mouse click on a
button tool bar just closes the tool tip and does nothing else.  When
there is no tool tip it works as expected.

When "Click Raise Active Window" is disabled, there is no problem.

Hope it will help.

Sincerely,
David

In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-10-19 on localhost
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Jan D.]

David PONCE wrote:
> Hi,
> 
> 
>>>It works for me with KDE 3.4.3 on Fedora Core 3. I checked that "Click
>>>Raise Active Window" is enabled. My Emacs is built --with-gtk.
>>
>>Could you try building without gtk, and see if you can reproduce the
>>problem?
> 
> 
> Sorry for the delay.  I rebuilt Emacs without GTK, and confirm that
> the bug is present.  When a tool tip is displayed, a mouse click on a
> button tool bar just closes the tool tip and does nothing else.  When
> there is no tool tip it works as expected.
> 
> When "Click Raise Active Window" is disabled, there is no problem.
> 

Sorry if these has been answered, I missed the start of the thread.

What focus policy do you have?  Also, in the window configuration dialog under 
"Actions", do you have "Pass Click" for the buttons in section "Inactive Inner 
Window"?  FWIW, I can not reporduce this problem, running KDE 3.4 under Fedora 
Core 4.

	Jan D.

Re: [Chong Yidong] Re: Tool-bar buttons unresponsive with tooltips on

[Jan D.]

>
>> Hi,
>>
>>>> It works for me with KDE 3.4.3 on Fedora Core 3. I checked that  
>>>> "Click
>>>> Raise Active Window" is enabled. My Emacs is built --with-gtk.
>>>>
>>>
>>> Could you try building without gtk, and see if you can reproduce the
>>> problem?
>>>
>> Sorry for the delay.  I rebuilt Emacs without GTK, and confirm that
>> the bug is present.  When a tool tip is displayed, a mouse click on a
>> button tool bar just closes the tool tip and does nothing else.  When
>> there is no tool tip it works as expected.
>> When "Click Raise Active Window" is disabled, there is no problem.
>>
>
> Sorry if these has been answered, I missed the start of the thread.
>
> What focus policy do you have?  Also, in the window configuration  
> dialog under "Actions", do you have "Pass Click" for the buttons in  
> section "Inactive Inner Window"?  FWIW, I can not reporduce this  
> problem, running KDE 3.4 under Fedora Core 4.

Actually I can reproduce this, but only with a non-GTK build.  I'm  
looking in to it.  The mouse click is passed to Emacs, but the
dpyinfo->mouse_face_window is incorrect when a tool tip is displayed.

     Jan D.

Re: Tool-bar buttons unresponsive with tooltips on

[Chong Yidong]

This patch fixes the bug.  However, it's pure hackery since I'm not
familiar with the code at all.  Can someone tell me if it makes sense
to do this?



*** emacs/src/xterm.c.~1.884.~	2005-10-17 08:54:26.000000000 -0400
--- emacs/src/xterm.c	2005-10-19 18:45:30.000000000 -0400
***************
*** 3609,3615 ****
        last_mouse_scroll_bar = Qnil;
        note_mouse_highlight (frame, event->x, event->y);
        /* Remember which glyph we're now on.  */
!       remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
        return 1;
      }
  
--- 3609,3616 ----
        last_mouse_scroll_bar = Qnil;
        note_mouse_highlight (frame, event->x, event->y);
        /* Remember which glyph we're now on.  */
!       if (!NILP (tip_frame) && frame != XFRAME (tip_frame))
! 	remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
        return 1;
      }

Re: Tool-bar buttons unresponsive with tooltips on

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Wed, 19 Oct 2005 18:49:03 -0400
> 
> This patch fixes the bug.  However, it's pure hackery since I'm not
> familiar with the code at all.  Can someone tell me if it makes sense
> to do this?

I don't have the answer to your question, but the snippet you changed
absolutely needs a comment that would explain its subtleties (as
discussed in this thread).

Re: Tool-bar buttons unresponsive with tooltips on

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> This patch fixes the bug.  However, it's pure hackery since I'm not
> familiar with the code at all.  Can someone tell me if it makes sense
> to do this?

It seems like you got the test wrong -- this looks more correct
to me:

      if (NILP (tip_frame) !! frame != XFRAME (tip_frame))
 	remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);

Does it still fix the bug with this change?  If so, feel free to
install the change with a suitable comment explaining why it is
needed.


>
> *** emacs/src/xterm.c.~1.884.~	2005-10-17 08:54:26.000000000 -0400
> --- emacs/src/xterm.c	2005-10-19 18:45:30.000000000 -0400
> ***************
> *** 3609,3615 ****
>         last_mouse_scroll_bar = Qnil;
>         note_mouse_highlight (frame, event->x, event->y);
>         /* Remember which glyph we're now on.  */
> !       remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
>         return 1;
>       }
>   
> --- 3609,3616 ----
>         last_mouse_scroll_bar = Qnil;
>         note_mouse_highlight (frame, event->x, event->y);
>         /* Remember which glyph we're now on.  */
> !       if (!NILP (tip_frame) && frame != XFRAME (tip_frame))
> ! 	remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
>         return 1;
>       }

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tool-bar buttons unresponsive with tooltips on

[Chong Yidong]

> It seems like you got the test wrong

Whoops.

> Does it still fix the bug with this change?

Unfortunately, no.  I'll keep on looking into it.

Re: Tool-bar buttons unresponsive with tooltips on

[Jan D.]

Chong Yidong wrote:
>>It seems like you got the test wrong
> 
> 
> Whoops.
> 
> 
>>Does it still fix the bug with this change?
> 
> 
> Unfortunately, no.  I'll keep on looking into it.
> 

I've checked in this change.  I hope it doesn't ruin the intent of calling 
remember_mouse_glyph in the first place.

	Jan D.


--- xterm.c	20 Oct 2005 15:04:13 -0000	1.885
+++ xterm.c	23 Oct 2005 21:10:30 -0000
@@ -3599,15 +3599,16 @@
        return 1;
      }

+  note_mouse_highlight (frame, event->x, event->y);
+
    /* Has the mouse moved off the glyph it was on at the last sighting?  */
    if (event->x < last_mouse_glyph.x
-	   || event->x >= last_mouse_glyph.x + last_mouse_glyph.width
-	   || event->y < last_mouse_glyph.y
-	   || event->y >= last_mouse_glyph.y + last_mouse_glyph.height)
+      || event->x >= last_mouse_glyph.x + last_mouse_glyph.width
+      || event->y < last_mouse_glyph.y
+      || event->y >= last_mouse_glyph.y + last_mouse_glyph.height)
      {
        frame->mouse_moved = 1;
        last_mouse_scroll_bar = Qnil;
-      note_mouse_highlight (frame, event->x, event->y);
        /* Remember which glyph we're now on.  */
        remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
        return 1;

Re: Tool-bar buttons unresponsive with tooltips on

[Jason Rumney]

"Jan D." <jan.h.d@swipnet.se> writes:

> I've checked in this change.  I hope it doesn't ruin the intent of
> calling remember_mouse_glyph in the first place.

The if statement is clearly trying to avoid calling note_mouse_highlight
for every pixel of mouse movement, since that was the only substantial
code inside the if statement originally. Moving note_mouse_highlight
outside the if block is certainly ruining the intent of that code.

I don't understand what note_mouse_highlight has to do with being able
to click the mouse on a toolbar button. I think if you can find the
reason why note_mouse_highlight affects that, you will be led to the
real bug.

Re: Tool-bar buttons unresponsive with tooltips on

[Jan D.]

23 okt 2005 kl. 23.54 skrev Jason Rumney:

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>
>> I've checked in this change.  I hope it doesn't ruin the intent of
>> calling remember_mouse_glyph in the first place.
>>
>
> The if statement is clearly trying to avoid calling  
> note_mouse_highlight
> for every pixel of mouse movement, since that was the only substantial
> code inside the if statement originally. Moving note_mouse_highlight
> outside the if block is certainly ruining the intent of that code.
>
> I don't understand what note_mouse_highlight has to do with being able
> to click the mouse on a toolbar button. I think if you can find the
> reason why note_mouse_highlight affects that, you will be led to the
> real bug.
>

I think the intent was to avoid doing frame->mouse_moved = 1, and  
note_mouse_highlight just happened to be there also.

The reason is that showing the tip window generates an EnterNotify  
event that clears dpyinfo->mouse_face_window (sets to Qnil).   
note_mouse_highlight calls note_tool_bar_highlight and that function  
sets mouse_face_window again to the tool bar window.  Later when  
checking if the click is in the tool bar, it is only recognised as a  
tool bar click if mouse_face_window is eq to the tool bar window.

Now, window managers are free to generate EnterNotify whenever they  
want and it seems that KDE generates one more than it used to, and  
also more than other window managers.  This is not a bug however.

     Jan D.

Re: Tool-bar buttons unresponsive with tooltips on

[Jason Rumney]

"Jan D." <jan.h.d@swipnet.se> writes:
>
> The reason is that showing the tip window generates an EnterNotify
> event that clears dpyinfo->mouse_face_window (sets to Qnil).

Why does it do that? tooltip windows should not affect any window
states.

> note_mouse_highlight calls note_tool_bar_highlight and that function
> sets mouse_face_window again to the tool bar window.  Later when
> checking if the click is in the tool bar, it is only recognised as a
> tool bar click if mouse_face_window is eq to the tool bar window.
>
> Now, window managers are free to generate EnterNotify whenever they
> want and it seems that KDE generates one more than it used to, and
> also more than other window managers.  This is not a bug however.

The EnterNotify may not be a bug, but the way we handle it is.
We should test for tip_window and avoid doing certain things, the same
way we do for other events.

Re: Tool-bar buttons unresponsive with tooltips on

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> Chong Yidong wrote:
>>>It seems like you got the test wrong
>> Whoops.
>> 
>>>Does it still fix the bug with this change?
>> Unfortunately, no.  I'll keep on looking into it.
>> 
>
> I've checked in this change.  I hope it doesn't ruin the intent of
> calling remember_mouse_glyph in the first place.
>
> 	Jan D.

It certainly ruins the intentions as Jason already pointed out.

Does this patch (vs. current CVS) fix the original problem?


*** xterm.c	24 Oct 2005 00:20:45 +0200	1.886
--- xterm.c	24 Oct 2005 11:08:59 +0200	
***************
*** 249,254 ****
--- 249,255 ----
  /* Where the mouse was last time we reported a mouse event.  */
  
  static XRectangle last_mouse_glyph;
+ static FRAME_PTR last_mouse_glyph_frame;
  static Lisp_Object last_mouse_press_frame;
  
  /* The scroll bar in which the last X motion event occurred.
***************
*** 3596,3616 ****
        frame->mouse_moved = 1;
        last_mouse_scroll_bar = Qnil;
        note_mouse_highlight (frame, -1, -1);
        return 1;
      }
  
-   note_mouse_highlight (frame, event->x, event->y);
  
    /* Has the mouse moved off the glyph it was on at the last sighting?  */
!   if (event->x < last_mouse_glyph.x
        || event->x >= last_mouse_glyph.x + last_mouse_glyph.width
        || event->y < last_mouse_glyph.y
        || event->y >= last_mouse_glyph.y + last_mouse_glyph.height)
      {
        frame->mouse_moved = 1;
        last_mouse_scroll_bar = Qnil;
        /* Remember which glyph we're now on.  */
        remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
        return 1;
      }
  
--- 3597,3620 ----
        frame->mouse_moved = 1;
        last_mouse_scroll_bar = Qnil;
        note_mouse_highlight (frame, -1, -1);
+       last_mouse_glyph_frame = 0;
        return 1;
      }
  
  
    /* Has the mouse moved off the glyph it was on at the last sighting?  */
!   if (frame != last_mouse_glyph_frame
!       || event->x < last_mouse_glyph.x
        || event->x >= last_mouse_glyph.x + last_mouse_glyph.width
        || event->y < last_mouse_glyph.y
        || event->y >= last_mouse_glyph.y + last_mouse_glyph.height)
      {
        frame->mouse_moved = 1;
        last_mouse_scroll_bar = Qnil;
+       note_mouse_highlight (frame, event->x, event->y);
        /* Remember which glyph we're now on.  */
        remember_mouse_glyph (frame, event->x, event->y, &last_mouse_glyph);
+       last_mouse_glyph_frame = frame;
        return 1;
      }
  
***************
*** 3821,3826 ****
--- 3825,3831 ----
  	       the frame are divided into.  */
  
  	    remember_mouse_glyph (f1, win_x, win_y, &last_mouse_glyph);
+ 	    last_mouse_glyph_frame = f1;
  
  	    *bar_window = Qnil;
  	    *part = 0;
***************
*** 6637,6643 ****
          int tool_bar_p = 0;
  
          bzero (&compose_status, sizeof (compose_status));
! 	bzero (&last_mouse_glyph, sizeof (last_mouse_glyph));
  
          if (dpyinfo->grabbed
              && last_mouse_frame
--- 6642,6648 ----
          int tool_bar_p = 0;
  
          bzero (&compose_status, sizeof (compose_status));
! 	last_mouse_glyph_frame = 0;
  
          if (dpyinfo->grabbed
              && last_mouse_frame

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tool-bar buttons unresponsive with tooltips on

[Chong Yidong]

> Does this patch (vs. current CVS) fix the original problem?

Yes it does.  Thanks.

Re: Tool-bar buttons unresponsive with tooltips on

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Does this patch (vs. current CVS) fix the original problem?
>
> Yes it does.  Thanks.

Good.  I have installed the patch for X.

Maybe a similar patch is needed on w32 and/or mac?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tool-bar buttons unresponsive with tooltips on

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>
>> The reason is that showing the tip window generates an EnterNotify
>> event that clears dpyinfo->mouse_face_window (sets to Qnil).
>>
>
> Why does it do that? tooltip windows should not affect any window
> states.

Probably an old leftover.  There should be a C variable to identify  
tip frames, like the hourglass_p variable.

>
>
>> note_mouse_highlight calls note_tool_bar_highlight and that function
>> sets mouse_face_window again to the tool bar window.  Later when
>> checking if the click is in the tool bar, it is only recognised as a
>> tool bar click if mouse_face_window is eq to the tool bar window.
>>
>> Now, window managers are free to generate EnterNotify whenever they
>> want and it seems that KDE generates one more than it used to, and
>> also more than other window managers.  This is not a bug however.
>>
>
> The EnterNotify may not be a bug, but the way we handle it is.
> We should test for tip_window and avoid doing certain things, the same
> way we do for other events.

Kim checked in another fix that works.

     Jan D.