unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Alan Third <alan@idiocy.org>
Cc: martin rudalics <rudalics@gmx.at>, emacs-devel <emacs-devel@gnu.org>
Subject: RE: Fix some tooltip related problems
Date: Wed, 10 Jan 2018 15:26:00 -0800 (PST)	[thread overview]
Message-ID: <7fbb8bd3-ebed-4e68-84b5-66bce36dc832@default> (raw)
In-Reply-To: <20180110230426.GB16679@breton.holly.idiocy.org>

> >    Given that limitation, I repeat the question: Can't we
> >    use a ("normal") Emacs frame, where things such as faces
> >    do work, to implement tooltips?
> 
> I believe it should be possible now we have undecorated frames
> available. I’ve made a (really bad) attempt at proving we can do it.
> Patch attached.
>
> My emacs lisp skills are rather bad, so I couldn’t work out how to get
> tooltip-hide to work, or how exactly I should set the size of the
> tooltip, or how to not display the modeline, but it kind of works...
> Someone who knows what they’re doing should be able to make a better
> fist of it than me.

Thanks for working on this.

I would hope that whatever implementation is ultimately used
is used for the existing functions (e.g. `x-tooltip-show'),
so that nothing changes for users/Lisp.

> One possible issue is that it might be difficult to stop frame‐based
> tooltips from crossing screens on multi‐monitor setups. I know we fix
> that in Objective‐C code in NS, I don’t know if lisp knows enough
> about screen geometry to get round it.

I don't think we should _necessarily_ force all of a tooltip's
text to be on a single monitor.  Though that might make sense
in some cases in others it might not.  At most, the ability to
do that would be a nice-to-have and not something needed or to
be imposed (IMO).

Put differently, it can be useful to _be able_ to position
_any_ frame so that it does not extend across monitors, when
possible.  But that shouldn't necessarily be imposed on any
frame, including, I think a tooltip.

> >    Did someone have to explain to you what a dimmed menu item
> >    is all about?  Is that inherently confusing the first time
> >    someone sees it?  I think not.  A tooltip with dimmed text
> >    is no more confusing.
> 
> I disagree, a menu item is interactive, or not if it’s dimmed, so it
> becomes clear quite quickly what dimming means. A dimmed tooltip is
> still a tooltip, just a bit harder to read. It takes further action to
> discover that the information its giving you isn’t currently usable.

That's reasonable.  Not a big deal/difference though (IMO).

The ability to get the general info is more important than
any possible confusion (which I expect to be none) someone
might have from not immediately understanding that dim means
that trying the indicated action produces no effect.



  reply	other threads:[~2018-01-10 23:26 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=7fbb8bd3-ebed-4e68-84b5-66bce36dc832@default \
    --to=drew.adams@oracle.com \
    --cc=alan@idiocy.org \
    --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 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).