* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
@ 2019-11-14 23:32 Juri Linkov
2019-11-15 8:13 ` martin rudalics
2019-11-15 8:26 ` Eli Zaretskii
0 siblings, 2 replies; 11+ messages in thread
From: Juri Linkov @ 2019-11-14 23:32 UTC (permalink / raw)
To: 38213
Some recent change caused tooltip frames to emit a new kind of event
'move-frame' (not sure should I try bisecting to find that commit)
that forces the mouse pointer in mouse-avoidance-mode to move
and thus removing the tooltip frame immediately after displaying it.
This patch adds handling of the new event 'move-frame':
diff --git a/lisp/avoid.el b/lisp/avoid.el
index 43e5062b76..9d6e502343 100644
--- a/lisp/avoid.el
+++ b/lisp/avoid.el
@@ -338,7 +338,7 @@ mouse-avoidance-ignore-p
(let ((modifiers (event-modifiers (car last-input-event))))
(or (memq (car last-input-event)
'(mouse-movement scroll-bar-movement
- select-window focus-out))
+ select-window focus-out move-frame))
(memq 'click modifiers)
(memq 'double modifiers)
(memq 'triple modifiers)
^ permalink raw reply related [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-14 23:32 bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode Juri Linkov
@ 2019-11-15 8:13 ` martin rudalics
2019-11-15 8:26 ` Eli Zaretskii
1 sibling, 0 replies; 11+ messages in thread
From: martin rudalics @ 2019-11-15 8:13 UTC (permalink / raw)
To: Juri Linkov, 38213
> Some recent change caused tooltip frames to emit a new kind of event
> 'move-frame' (not sure should I try bisecting to find that commit)
MOVE_FRAME_EVENT exists since 2017-04-11, commit
ea6c880aa68bcc8f0e388ecbd8c552392488b38f.
martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-14 23:32 bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode Juri Linkov
2019-11-15 8:13 ` martin rudalics
@ 2019-11-15 8:26 ` Eli Zaretskii
2019-11-15 8:53 ` martin rudalics
1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-11-15 8:26 UTC (permalink / raw)
To: Juri Linkov; +Cc: 38213
> From: Juri Linkov <juri@linkov.net>
> Date: Fri, 15 Nov 2019 01:32:03 +0200
>
> Some recent change caused tooltip frames to emit a new kind of event
> 'move-frame' (not sure should I try bisecting to find that commit)
> that forces the mouse pointer in mouse-avoidance-mode to move
> and thus removing the tooltip frame immediately after displaying it.
>
> This patch adds handling of the new event 'move-frame':
Shouldn't we instead avoid emitting this event when a tooltip frame is
positioned? Otherwise, we will have to make such adaptations in many
places.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-15 8:26 ` Eli Zaretskii
@ 2019-11-15 8:53 ` martin rudalics
2019-11-15 9:50 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: martin rudalics @ 2019-11-15 8:53 UTC (permalink / raw)
To: Eli Zaretskii, Juri Linkov; +Cc: 38213
> Shouldn't we instead avoid emitting this event when a tooltip frame is
> positioned? Otherwise, we will have to make such adaptations in many
> places.
Doesn't the tooltip frame get removed because 'mouse-avoidance-mode'
reacts to a movement of the normal frame that "hosts" the tooltip
frame.
martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-15 8:53 ` martin rudalics
@ 2019-11-15 9:50 ` Eli Zaretskii
2019-11-15 16:35 ` martin rudalics
0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-11-15 9:50 UTC (permalink / raw)
To: martin rudalics; +Cc: 38213, juri
> Cc: 38213@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 15 Nov 2019 09:53:37 +0100
>
> > Shouldn't we instead avoid emitting this event when a tooltip frame is
> > positioned? Otherwise, we will have to make such adaptations in many
> > places.
>
> Doesn't the tooltip frame get removed because 'mouse-avoidance-mode'
> reacts to a movement of the normal frame that "hosts" the tooltip
> frame.
But the normal frame which hosts the tooltip is not moved in this
scenario. To reproduce, turn on mouse-avoidance-mode (I used 'jump'
as the avoidance technique), then start Dired, and move the mouse to
the file name under cursor. Here, the tooltip appears and immediately
disappears, and I see no movement of the "hosting" frame anywhere.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-15 9:50 ` Eli Zaretskii
@ 2019-11-15 16:35 ` martin rudalics
2019-11-15 16:57 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: martin rudalics @ 2019-11-15 16:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38213, juri
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
> But the normal frame which hosts the tooltip is not moved in this
> scenario. To reproduce, turn on mouse-avoidance-mode (I used 'jump'
> as the avoidance technique), then start Dired, and move the mouse to
> the file name under cursor. Here, the tooltip appears and immediately
> disappears, and I see no movement of the "hosting" frame anywhere.
Hmm... So you think that something like the attached should be
applied?
martin
[-- Attachment #2: move-frame.diffs --]
[-- Type: text/plain, Size: 969 bytes --]
diff --git a/src/w32term.c b/src/w32term.c
index d0537c67e9..17bf408c20 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5314,7 +5314,8 @@ w32_read_socket (struct terminal *terminal,
case WM_MOVE:
f = w32_window_to_frame (dpyinfo, msg.msg.hwnd);
- if (f && FRAME_VISIBLE_P (f) && !FRAME_ICONIFIED_P(f))
+ if (f && FRAME_VISIBLE_P (f) && !FRAME_ICONIFIED_P(f)
+ && !FRAME_TOOLTIP_P (f))
{
w32_real_positions (f, &f->left_pos, &f->top_pos);
inev.kind = MOVE_FRAME_EVENT;
diff --git a/src/xterm.c b/src/xterm.c
index f7005804f0..d55bc3890d 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -9032,7 +9032,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
unblock_input ();
}
- if (old_left != f->left_pos || old_top != f->top_pos)
+ if (!FRAME_TOOLTIP_P (f)
+ && (old_left != f->left_pos || old_top != f->top_pos))
{
inev.ie.kind = MOVE_FRAME_EVENT;
XSETFRAME (inev.ie.frame_or_window, f);
^ permalink raw reply related [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-15 16:35 ` martin rudalics
@ 2019-11-15 16:57 ` Eli Zaretskii
2019-11-16 8:19 ` martin rudalics
0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-11-15 16:57 UTC (permalink / raw)
To: martin rudalics; +Cc: 38213, juri
> Cc: juri@linkov.net, 38213@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 15 Nov 2019 17:35:42 +0100
>
> > But the normal frame which hosts the tooltip is not moved in this
> > scenario. To reproduce, turn on mouse-avoidance-mode (I used 'jump'
> > as the avoidance technique), then start Dired, and move the mouse to
> > the file name under cursor. Here, the tooltip appears and immediately
> > disappears, and I see no movement of the "hosting" frame anywhere.
>
> Hmm... So you think that something like the attached should be
> applied?
Yes, I think so.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-15 16:57 ` Eli Zaretskii
@ 2019-11-16 8:19 ` martin rudalics
2019-11-21 21:31 ` Juri Linkov
0 siblings, 1 reply; 11+ messages in thread
From: martin rudalics @ 2019-11-16 8:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38213, juri
>> Hmm... So you think that something like the attached should be
>> applied?
>
> Yes, I think so.
Applied.
martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-16 8:19 ` martin rudalics
@ 2019-11-21 21:31 ` Juri Linkov
2019-11-22 8:09 ` martin rudalics
0 siblings, 1 reply; 11+ messages in thread
From: Juri Linkov @ 2019-11-21 21:31 UTC (permalink / raw)
To: martin rudalics; +Cc: 38213
tags 38213 fixed
close 38213 27.0.50
quit
>>> Hmm... So you think that something like the attached should be
>>> applied?
>>
>> Yes, I think so.
>
> Applied.
Thanks. I still can't find an explanation why there was no problem
until recently, but since it works now I'm closing this report.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-21 21:31 ` Juri Linkov
@ 2019-11-22 8:09 ` martin rudalics
2019-11-26 22:12 ` Juri Linkov
0 siblings, 1 reply; 11+ messages in thread
From: martin rudalics @ 2019-11-22 8:09 UTC (permalink / raw)
To: Juri Linkov; +Cc: 38213
> Thanks. I still can't find an explanation why there was no problem
> until recently, but since it works now I'm closing this report.
Maybe because you only used GTK's native tooltips until recently?
martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode
2019-11-22 8:09 ` martin rudalics
@ 2019-11-26 22:12 ` Juri Linkov
0 siblings, 0 replies; 11+ messages in thread
From: Juri Linkov @ 2019-11-26 22:12 UTC (permalink / raw)
To: martin rudalics; +Cc: 38213
>> Thanks. I still can't find an explanation why there was no problem
>> until recently, but since it works now I'm closing this report.
>
> Maybe because you only used GTK's native tooltips until recently?
This is exactly what happened (I didn't know that GTK builds use native tooltips)
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-11-26 22:12 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-14 23:32 bug#38213: 27.0.50; add tooltip move-frame handling to mouse-avoidance-mode Juri Linkov
2019-11-15 8:13 ` martin rudalics
2019-11-15 8:26 ` Eli Zaretskii
2019-11-15 8:53 ` martin rudalics
2019-11-15 9:50 ` Eli Zaretskii
2019-11-15 16:35 ` martin rudalics
2019-11-15 16:57 ` Eli Zaretskii
2019-11-16 8:19 ` martin rudalics
2019-11-21 21:31 ` Juri Linkov
2019-11-22 8:09 ` martin rudalics
2019-11-26 22:12 ` Juri Linkov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).