[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Fix some tooltip related problems
From: |
Drew Adams |
Subject: |
RE: Fix some tooltip related problems |
Date: |
Wed, 10 Jan 2018 15:26:00 -0800 (PST) |
> > 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.
- RE: Fix some tooltip related problems, (continued)
- RE: Fix some tooltip related problems, Drew Adams, 2018/01/08
- Re: Fix some tooltip related problems, martin rudalics, 2018/01/08
- RE: Fix some tooltip related problems, Drew Adams, 2018/01/08
- Re: Fix some tooltip related problems, martin rudalics, 2018/01/09
- RE: Fix some tooltip related problems, Drew Adams, 2018/01/09
- Re: Fix some tooltip related problems, martin rudalics, 2018/01/10
- RE: Fix some tooltip related problems, Drew Adams, 2018/01/10
- Re: Fix some tooltip related problems, Alan Third, 2018/01/10
- RE: Fix some tooltip related problems, Drew Adams, 2018/01/10
- Re: Fix some tooltip related problems, Alan Third, 2018/01/10
- RE: Fix some tooltip related problems,
Drew Adams <=
- Re: Fix some tooltip related problems, Eli Zaretskii, 2018/01/10
- Re: Fix some tooltip related problems, Yuri Khan, 2018/01/11
- RE: Fix some tooltip related problems, Drew Adams, 2018/01/11
- Re: Fix some tooltip related problems, martin rudalics, 2018/01/11
- RE: Fix some tooltip related problems, Drew Adams, 2018/01/11
- Re: Fix some tooltip related problems, martin rudalics, 2018/01/11
- Re: Fix some tooltip related problems, Robert Pluim, 2018/01/11
- Re: Fix some tooltip related problems, Eli Zaretskii, 2018/01/11
- Re: Fix some tooltip related problems, martin rudalics, 2018/01/11
- Re: Fix some tooltip related problems, Daniele Nicolodi, 2018/01/11