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