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.
next prev parent 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).