all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>, emacs-devel <emacs-devel@gnu.org>
Subject: RE: Fix some tooltip related problems
Date: Thu, 11 Jan 2018 11:50:10 -0800 (PST)	[thread overview]
Message-ID: <ec21a1ef-9fd4-460d-8722-138a3fe8f3e5@default> (raw)
In-Reply-To: <5A57B302.5090108@gmx.at>

>  > 1. Can users with a GTK build today use Lisp code that decides
>  > which to use in any given (Lisp) context?  How is that done
>  > in Lisp?
> 
> The option `x-gtk-use-system-tooltips' decides whether to use system
> or Emacs tooltips.  This is a user option and should never be set by
> Lisp code.

Then that doesn't satisfy what I requested:

  "being able to choose for any given context which to use"
                        ---------------------
  "Can we let Lisp code (and so users too) decide, here or
   there, which kind of tooltip to use (heavyweight "Emacs"
   or lightweight "system")?"

>  > 2. What do you mean by "set up tooltip controls" on Windows?
>
> Windows uses the term "tooltip controls" for its native tooltips.  In
> order to use tooltip controls, an application programmer has to set
> them up, that is, write the necessary API routines.

So if no one "has the time to set up tooltip controls on
Windows" then we have what we have now on Windows: "Emacs"
tooltips - which is fine.

>  > Today, on Windows you can at least use faces in tooltips.
>  > (Dunno about using images, but I'm guessing that's OK too.)
> 
> A tooltip frame is a normal top-level frame that can be used like any
> other frame.  It has some restrictions (no margins, fringes, scroll
> bars) but a criminal mind might be able to relieve some of them.

That's all good, and what I expected but wasn't sure -
"Emacs" tooltips are plenty flexible.

>  > But perhaps you mean that on Windows there are _only_
>  > "Emacs" tooltips, not "system" tooltips?  From my point of
>  > view that's not a problem - flexible beats inflexible.  You
>  > say that tooltips on Windows are "heavyweight" and "incur
>  > an entire GC cycle", but I've never noticed any performance
>  > problem with them - on Emacs 20 through 26.
> 
> Probably because you don't use a battery or maybe you just don't care.

I don't use a battery.

I guess you're suggesting that "Emacs" tooltips, which are
apparently all we have on Windows, are too slow for use with
a battery.  And you expect that no one will provide the
choice of "system" tooltips on Windows.

So from your point of view, tooltips on Windows should
typically be turned off (at least by users) when a battery
is used, so the info goes to the echo area.  That's OK.

Ignoring any battery users on Windows who don't turn off
tooltips, we have what we need on Windows.  (Yes, a Lisp
choice would be even better, but if no one provides it...)

And users on gtk-build systems can choose.  Choice should
also be available to Lisp functions, as use cases differ.
It's of course possible to let a user option allow for
Lisp control or override/prevent it, au choix.

Today, does changing the value of that user option change
the behavior dynamically?  E.g., if you did change the
value using a given Lisp function would the behavior change?

If so then some specific contexts could, by default, use
"Emacs" tooltips, while other contexts did not.

For example, tooltip-dimming for mode-line mouseover
could be done for non-Windows also, without imposing "Emacs"
tooltips everywhere.  And users could prevent that dimming
using option `x-gtk-use-system-tooltips'.

Since that's apparently possible for more than just Windows,
including for at least some GNU/Linux builds, that's what
we should do by default.  I didn't propose it earlier
because I thought you were saying that it is only Windows
that supports faces in tooltips, and I know that we don't
tailor default Emacs behavior for Windows only.



  reply	other threads:[~2018-01-11 19:50 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08  9:53 Fix some tooltip related problems martin rudalics
2018-01-08 14:41 ` Drew Adams
2018-01-08 18:19   ` martin rudalics
2018-01-08 18:50     ` Drew Adams
2018-01-09  9:42       ` martin rudalics
2018-01-09 15:08         ` Drew Adams
2018-01-10 10:20           ` martin rudalics
2018-01-10 15:55             ` Drew Adams
2018-01-10 19:17               ` Alan Third
2018-01-10 21:02                 ` Drew Adams
2018-01-10 23:04                   ` Alan Third
2018-01-10 23:26                     ` Drew Adams
2018-01-11  3:39                   ` Eli Zaretskii
2018-01-11  7:03                 ` Yuri Khan
2018-01-11 14:32                   ` Drew Adams
2018-01-11 10:56               ` martin rudalics
2018-01-11 14:42                 ` Drew Adams
2018-01-11 17:06                   ` martin rudalics
2018-01-11 17:19                     ` Robert Pluim
2018-01-11 17:59                       ` Eli Zaretskii
2018-01-11 18:20                         ` martin rudalics
2018-01-11 23:33                         ` Daniele Nicolodi
2018-01-12  8:38                           ` Eli Zaretskii
2018-01-12  8:40                         ` Robert Pluim
2018-01-12  9:55                           ` Eli Zaretskii
2018-01-12 13:57                             ` Robert Pluim
2018-01-12 14:15                               ` Philipp Stephani
2018-01-11 19:54                       ` Richard Stallman
2018-01-11 23:26                       ` Stefan Monnier
2018-01-12  8:48                         ` Robert Pluim
2018-01-11 18:09                     ` Drew Adams
2018-01-11 18:54                       ` martin rudalics
2018-01-11 19:50                         ` Drew Adams [this message]
2018-01-12  8:47                           ` martin rudalics
2018-01-12 16:43                             ` Drew Adams
2018-01-08 18:47 ` Eli Zaretskii
2018-01-08 19:06   ` martin rudalics
2018-01-08 19:22     ` Eli Zaretskii
2018-01-09  9:42       ` martin rudalics
2018-01-19 18:54 ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec21a1ef-9fd4-460d-8722-138a3fe8f3e5@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.