GNU bug report logs - #40513
Tooltips with images

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40513 in the body.
You can then email your comments to 40513 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Andreas Matthias <andreas.matthias <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Tooltips with images
Date: Wed, 8 Apr 2020 22:49:48 +0200

[Message part 1 (text/plain, inline)]

This bug report is probably related to #40047.

I experience some weird behavior with tooltips.

(progn
  (let* ((start (point))
         (end (progn (insert "test") (point)))
         (ov (make-overlay start end)))
    (overlay-put ov 'help-echo
                 (propertize "xxx" 'display '(image :type jpeg :file
"~/foo.jpg"))))
  (display-buffer-other-frame (get-buffer-create "dummy")))


After evaluating this code (Do not click anywhere, this is important.)
and moving the mouse pointer over "test" I get a tooltip displaying the
image file foo.jpg. The tooltip appears as a box with a light yellow
background color with sharp corners.

But the moment I click anywhere on the desktop (not necessarily on an
emacs frame) this tooltip changes it's appearance. Now
the tooltip contains no image but the text "xxx". Furthermore the tooltip
appears as a transparent black box with rounded corners.

I suppose that the first tooltip I'm seeing is an emacs-tooltip while
the second one is a gtk-tooltip.

The code line creating an empty buffer is important. Without this line I
never see the emacs-tooltip, but always the gtk-tooltip.

The tests were done with (setq x-gtk-use-system-tooltips t).

After setting (setq x-gtk-use-system-tooltips nil) the tooltip does not
change any more. Now I always get an emacs-tooltip.




In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30,
cairo version 1.15.10)
 of 2020-03-17 built on phoenix
Repository revision: ac9acc1864b02b92de4eb2e98db7b5b0cd03e019
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.4 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
funcall-interactively: End of buffer [3 times]

Configured using:
 'configure --with-imagemagick'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND DBUS GSETTINGS GLIB
NOTIFY INOTIFY GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 44799 5180)
 (symbols 48 6297 1)
 (strings 32 15693 1667)
 (string-bytes 1 509547)
 (vectors 16 9297)
 (vector-slots 8 127644 10640)
 (floats 8 20 31)
 (intervals 56 194 0)
 (buffers 1000 12))

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andreas Matthias <andreas.matthias <at> gmail.com>, 40513 <at> debbugs.gnu.org
Subject: Re: bug#40513: Tooltips with images
Date: Sat, 11 Apr 2020 10:32:37 +0200

> This bug report is probably related to #40047.

Despite the fact that both reports ask for tooltips to show images, they
are not related.  The behavior you see can be easily reproduced without
using an image as display property.

> I experience some weird behavior with tooltips.
>
> (progn
>    (let* ((start (point))
>           (end (progn (insert "test") (point)))
>           (ov (make-overlay start end)))
>      (overlay-put ov 'help-echo
>                   (propertize "xxx" 'display '(image :type jpeg :file
> "~/foo.jpg"))))
>    (display-buffer-other-frame (get-buffer-create "dummy")))
>
>
> After evaluating this code (Do not click anywhere, this is important.)
> and moving the mouse pointer over "test" I get a tooltip displaying the
> image file foo.jpg. The tooltip appears as a box with a light yellow
> background color with sharp corners.
>
> But the moment I click anywhere on the desktop (not necessarily on an
> emacs frame) this tooltip changes it's appearance. Now
> the tooltip contains no image but the text "xxx". Furthermore the tooltip
> appears as a transparent black box with rounded corners.
>
> I suppose that the first tooltip I'm seeing is an emacs-tooltip while
> the second one is a gtk-tooltip.

Correct.

> The code line creating an empty buffer is important. Without this line I
> never see the emacs-tooltip, but always the gtk-tooltip.

The crucial aspect here is that of popping up a new frame.

> The tests were done with (setq x-gtk-use-system-tooltips t).
>
> After setting (setq x-gtk-use-system-tooltips nil) the tooltip does not
> change any more. Now I always get an emacs-tooltip.

The behavior you experience is strange and I have no full explanation
for it.  From the Emacs side it's all quite clear: When you move the
mouse over "test", Emacs is informed that it should provide a tooltip
text and position.  When it tries to show that tooltip via 'x-show-tip'
in xfns.c, that function calls xg_prepare_tooltip in gtkutil.c which
returns FALSE because the value of the tooltip label (ttip_lbl) for the
frame showing dummy has not been assigned yet (qttip_cb has not been run
for that frame yet).

As a consequence, the value of OK in 'x-show-tip' is false and due to
its logic 'x-show-tip' assumes that for some reason GTK cannot show the
tooltip and it will try to show a native Emacs tooltip instead.  That's
what you see first.  Later, and in particular after you have clicked
into any of your frames, the values of ttip_lbl will have been orderly
set up for all frames and you will see the GTK tooltips as requested.

Why GTK asks us to display the tooltip _for_ the dummy frame is beyond
my knowledge.  It's probably due to the fact that our window managers
automatically put focus on the new, dummy frame while the mouse pointer
hovers over the old *scratch* frame without selecting/focusing it.  Try
your example with

(setq default-frame-alist '((no-focus-on-map . t)))

set initially and you shouldn't be able to reproduce your scenario.

Note that I can reproduce your behavior despite of the fact that I'm
using focus follows mouse - as long as I don't move the mouse from
_elsewhere_ into the *scratch* frame, that frame does not get focus.  So
here I just have to make sure that the mouse pointer will be over the
*scratch* frame when the dummy frame gets created.  Unfortunately, the
problem cannot be debugged via GDB because anything you do in the
debugger window will distract the original focus.

In either case, I don't think that all this should be of any importance
for you: If you want to show an image in a tooltip, you will have to use
the native Emacs tooltip anyway, so set 'x-gtk-use-system-tooltips' to
nil and you are done.  If you insist on using GTK tooltips (something I
recommend only to hardcore GTK fans) you will have to live with the fact
that sometimes a native Emacs tooltip will pop up in case GTK has not
caught up with initializing the tooltip data for a new frame.

martin

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 40513 <at> debbugs.gnu.org, Andreas Matthias <andreas.matthias <at> gmail.com>
Subject: Re: bug#40513: Tooltips with images
Date: Thu, 18 Aug 2022 11:27:37 -0700

tags 40513 + wontfix
close 40513
thanks

martin rudalics <rudalics <at> gmx.at> writes:

> In either case, I don't think that all this should be of any importance
> for you: If you want to show an image in a tooltip, you will have to use
> the native Emacs tooltip anyway, so set 'x-gtk-use-system-tooltips' to
> nil and you are done.  If you insist on using GTK tooltips (something I
> recommend only to hardcore GTK fans) you will have to live with the fact
> that sometimes a native Emacs tooltip will pop up in case GTK has not
> caught up with initializing the tooltip data for a new frame.

No further comments within over 2 years.  From reading the bug report
and Martin's reply, it sounds like we are okay with the way things are
currently.  I'm therefore closing this bug report.

If this conclusion is incorrect and this is still an issue, please reply
to this email (use "Reply to all" in your email client) and we can
reopen the bug report.

Previous Next

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