| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2584
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | A timer to make tooltips hide themselves after a period of time |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.4.0 |
|---|
| Fix Commit: | 2be4d720ab2c97720a7ebb0a4c34581ed7df58fb |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | greg.ercolano
01:27 Mar 05, 2011 |
| Would be nice if tooltips by default would automatically disappear after some period of time (10 secs or so, perhaps reconfigurable).
FLTK apps seem unique in that tooltips can remain open 'forever' if there's no user input, which is a nuisance, as they eclipse parts of the app (and other apps) with their messages. | |
| |
| #2 | manolo
05:07 Mar 05, 2011 |
| Firefox seems to behave just as FLTK: the tooltip remains on forever
unless the mouse leaves the widget or user input begins. | |
| |
| #3 | greg.ercolano
09:58 Mar 05, 2011 |
| Ha, true! (Luckily I said FLTK "seems" unique.. ;)
Situations where the tooltips go away:
Entire KDE Desktop: Konqueror, Konsole, kdict..
Entire Win7 desktop: Control panel,'Start' menu,'X' close win buttons..
Entire Mac desktop: Safari, System Prefs, ITunes..
For the Mac I sampled both tiger and snow lep, so it's been in there for a while. For KDE I sampled Ubuntu 8 and FC14.
Since all the desktops are going with it, it seems to be a direction things are going. It also seems practical. | |
| |
| #4 | AlbrechtS
08:26 Mar 06, 2011 |
| I tried Firefox and Tunderbird on Win7, and for me it looks like this:
- tooltip stays forever, if the mouse is not moved
- tooltip closes, if the mouse moves more than a few pixels from the
origin, where the tooltip was triggered for the first time
(you can move the mouse in a small circle as long as you like)
- if it was closed, it doesn't reappear until the current widget is
left and entered again
- there are exceptions to the previous rule (sometimes it *does* come
back again)
I think these rules are generally reasonable. If you want to read a tooltip for a longer time, keep the mouse where it is. If you want to dismiss the tooltip, move the mouse again, but stay within the widget or area that is responsible for this particular tooltip.
FLTK seems to close the tooltip only if the mouse moves at/over the tooltip window, but then it is opened again at another spot. I agree that this is not very useful.
I believe that a simple timeout is not very user friendly. Either it's too long or too short, and changing it globally wouldn't help because there are longer and shorter tooltips, or you know them already after a while...
Maybe we could implement something like the rules described above? I didn't look at the code, it's just my observation... | |
| |
| #5 | greg.ercolano
10:18 Mar 06, 2011 |
| OK, let's not get distracted by Mozilla's model. Did I mention *all* the current desktops, /all three platforms/, use tooltip timeouts for their toolbars and apps? Cross platform agreement on desktop behavior is rare ;) I'd be surprised if Mozilla didn't adopt this in a future release.
Mozilla and Desktops aside, it would at least be good if the FLTK API provided a way for an app to do this. As it is, I don't think it does. (If there is, let me know).
I don't fully understand Fl_Tooltip's implementation, but I get the impression there's a single global instance of it somewhere, and all widget's tooltips communicate with it.
I could see perhaps at minimum an Fl_Tooltip::callback() that an app can set to be notified whenever a tooltip is posted or hidden, eg:
enum { SHOWN, HIDDEN }; // Fl_Tooltip::{SHOWN|HIDDEN}
typedef void (Fl_Tooltip_Callback)(Fl_Widget* w, // tooltip's widget
int notify, // SHOWN | HIDDEN
void* data); // user data
Fl_Tooltip::callback(Fl_Tooltip_Callback *cb, void *data);
..and probably a public method to tell posted tooltips to hide():
Fl_Tooltip::hide()
So two additional public static methods, and a public Fl_Tooltip:: enum.
With that, an app could get a callback when a tooltip is posted:
if SHOWN, setup timeout to hide eg. based on strlen(w->tooltip()),
if HIDDEN, disable any timeout it setup,
on timeout, hide the current tooltip.
And if the time ever came where the API should provide tooltip timeouts itself, a simple method:
Fl_Tooltip::hidedelay(float secs)
the above would still be useful to allow apps to fine tune tooltip times based on some algorithm of its own. I imagine a single method of the form:
Fl_Tooltip::hidedelay(float secs)
private: static float hidedelay_; // !< delay to hide tooltip
..where 0.0 is disabled (eg. 'forever').
This would catch us up with QT, which has had tooltip kill timers for >5 years, and only recently added the ability to allow users to adjust the kill timer:
http://www.qtcentre.org/threads/8645-Tooltip-delays
http://bugreports.qt.nokia.com/browse/QTBUG-1016 | |
| |
| #6 | matt
14:57 Feb 02, 2019 |
| Fixed in Git repository. | |
| |
| #7 | greg.ercolano
15:47 Feb 02, 2019 |
| Fl_Tooltip::hide_delay() -- yay!
(I see a small typo in the docs; s/unitl/until/g ;)
_________________________________________________________
/** Gets the time unitl an open tooltip hides again.
The default delay is 12.0 seconds. */
static float hidedelay() { return hidedelay_; }
/** Sets the time unitl an open tooltip hides again.
The default delay is 12.0 seconds. */
static void hidedelay(float f) { hidedelay_ = f; } | |
| |
| #8 | matt
15:49 Feb 02, 2019 |
| Fixed typo | |
[ Return to Bugs & Features ]
|
| |
