[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix some tooltip related problems

From: Alan Third
Subject: Re: Fix some tooltip related problems
Date: Wed, 10 Jan 2018 23:04:26 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Wed, Jan 10, 2018 at 01:02:42PM -0800, Drew Adams wrote:
>    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.

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.

(BTW, I just noticed that under NS toolbar tooltips are native, while
other tooltips aren’t.)

>    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.

Alan Third

Attachment: 0001-Implement-rubbish-frame-base-tooltips.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]