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