Issue590

classification
Title Improving tooltip support
Type feature Module core code 21.4, core code 21.5, core code 21.6, core code 21.7
Severity inconvenience Platform N/A
Keywords Nosy List stephen
explanation
process
These controls should only be changed by committers and tracker administrators.
Status assigned   Reason
Superseder   Submitted 2009-10-12.10:17:40
Priority urgent   Assigned To

Created on 2009-10-12.10:42:15 by stephen, last changed 2013-12-02.12:30:00 by stephen.

Messages
msg1914 [hidden] ([hidden]) Date: 2009-10-13.09:46:38
  Message-ID: <8763ajisb4.fsf@lola.goethe.zz>
"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > "reliable" means that using it does not crash the Windows port.
>
> Oof!  That hurts.  It's not something I can fix.
>
>  > Further features of the XEmacs model I remember were:
>  > 
>  > a) it pops up with a noticeable time delay (likely X overhead for frame
>  > creation) during which XEmacs is non-responsive
>
> IIRC that's broken by design (you need to hover over the object for a
> second or XEmacs decides it was an accident and you didn't want a
> tip).

The time delay before XEmacs decides to pop up the tooltip is fine.  The
non-responsiveness while it works on the popup isn't.

>  > b) it steals the keyboard focus on mouse-over-frame window managers
>  > if you have bad luck (move the mouse cursor at the wrong time/the
>  > wrong direction)
>
> I think I fixed that.
>
>  > c) it comes with frame decorations
>
> I definitely fixed that.

It has been some time since I bothered checking since we stopped
enabling XEmacs tooltips in preview-latex after numerous user
complaints.

>  > All of Emacs' standard menu entries have tooltips (I don't even
>  > think that XEmacs supports menu entries with tooltips)
>
> I'll look at that.

Even if you choose not to implement them in menu entries, it would make
things easier for package developers if the menu system did not reject
the :help specifications but just ignored them.

That would obviate the need for something like

    TeX-menu-with-help is a Lisp macro in `tex.el'.

    (TeX-menu-with-help MENU)

    Compatibility macro that removes :help entries if on XEmacs.
    Also does other stuff.

> Thank you for your careful report.

Not particularly careful, just working from memory.  The ultimate metric
is "does not get in the way".  Once that metric is reached, one can
enable them by default.  We finally had to disable tooltips for the
XEmacs port because we got too many user complaints.  I'll leave it to
XEmacs proper to change the default.
msg1908 [hidden] ([hidden]) Date: 2009-10-12.17:49:27
David Kastrup responds:

"reliable" means that using it does not crash the Windows port.  Further 
features of the XEmacs model I remember were: 
 
a) it pops up with a noticeable time delay (likely X overhead for frame 
creation) during which XEmacs is non-responsive 
b) it steals the keyboard focus on mouse-over-frame window managers if 
you have bad luck (move the mouse cursor at the wrong time/the wrong 
direction) 
c) it comes with frame decorations 
 
Please note that Emacs tooltips are _not_, I repeat _not_ optional.  Why 
doesn't one get a protest storm from users?  Because they don't 
interfere with normal operation.  They are undecorated, they disappear 
as soon as the mouse moves again, they cause no delays and never steal 
the keyboard focus, they never obstruct areas where mouse or text cursor 
are for any amount of time. 
 
All of Emacs' standard menu entries have tooltips (I don't even think 
that XEmacs supports menu entries with tooltips), and pretty much 
everything in mode lines.
msg1905 [hidden] ([hidden]) Date: 2009-10-12.10:42:15
  Message-ID: <87d44skjaz.fsf@uwakimon.sk.tsukuba.ac.jp>
Broken out of the "tiny inefficieny in `beginning-of-defun-raw',
lisp.el" thread.  This should show up shortly on the tracker with the
subject above.

 > Again, we are not talking "API differences".  XEmacs does not have
 > reliable tooltips,

I believe with some functions I've provided (about 4 years ago) its
tooltips are very close to reliable now on 21.4 as well as 21.5, but I
can't be sure because that's only in personal use, which is only to
provide the proof of concept, and the API probably sucks too.  Both of
those issues are because nobody else is using it.  However, it is
nearly impossible to use the Emacs API to broaden the audience because
XEmacs tooltips function completely differently.  That *is* a question
of API difference, and the only way I can see to deal with is to
provide a fsf-compat emulation of the Emacs API, if that's possible.
I didn't find a way at the time.

So what is a "reliable tooltip"?  (Don't tell me to look at Emacs, I
need to know what behavior needs to be supported that XEmacs doesn't,
not what an alternative implementation does.)

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@calypso.tux.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
History
Date User Action Args
2013-12-02 12:30:00stephensetstatus: closed -> assigned
2013-08-24 00:31:40vimRULESsetstatus: assigned -> closed
2009-10-15 04:45:41stephensetstatus: new -> assigned
priority: normal -> urgent
assignedto: stephen
2009-10-13 09:46:38stephensetmessages: + msg1914
2009-10-12 17:49:28stephensetmessages: + msg1908
2009-10-12 14:37:29stephensetstatus: new
severity: inconvenience
module: + core code 21.4, core code 21.5, core code 21.6, core code 21.7
priority: normal
platform: + N/A
type: feature
2009-10-12 10:42:16stephencreate