GNU bug report logs - #27647
26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

Previous Next

Full log

Message #171 received at 27647 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 27647 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com, agrambot <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#27647: 26.0.50; Line numbers implemented natively disappear
 momentarily when frame out of focus
Date: Mon, 13 Nov 2017 21:12:26 +0200

> Date: Mon, 13 Nov 2017 19:45:40 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: npostavs <at> users.sourceforge.net, agrambot <at> gmail.com, 
>  27647 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
> 
>  > Not exactly.  tip_frame should be nil when GTK pops a native tooltip,
>  > then tip_frame will get its simple semantics back.
> 
> x_hide_tip uses NILP (tip_frame) to decide whether to hide the tip.

That's non-GTK code which GTK doesn't need, but left it alone.  The
whole GTK support in x_hide_tip is patched over the non-GTK code, with
dirty tricks like setting tip_frame to nil just to bypass the non-GTK
part of the function.  We will be better off with a separate GTK-only
implementation.

> IIUC GTK doesn't need the original frame.

xg_hide_tooltip needs it, because the GTK tooltip widget is stashed
away in its output->data.x structure.

> But it sets tooltip_frame to it so Fx_show_tip and friends can base
> their decisions on it.  Look at occurrences of FRAMEP (tip_frame)
> and FRAME_LIVE_P (XFRAME (tip_frame)).  They pass because for GTK
> tip_frame is a live frame associated with the tooltip.  Jan tried
> hard to leave the native tooltip code untouched.

Once again, it would be better to have the GTK code completely
separated, IMO.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.