| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2650
| 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 tooltip is sometimes placed under the cursor, where it flashes and flashes |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | corvid |
|---|
| Assigned To: | cand |
|---|
| Fix Version: | 1.3-current (SVN: v10473) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | corvid
11:10 May 30, 2011 |
| With a large tooltip -- here's one that Dillo sees on lkml.org right now:
widget->tooltip("&quot;Witold Baryluk&quot; writes: (Summary) \n<br/>\nBug is preserved at multiple kernel configs.<br/>\nI send one which is pretty minimized.<br/>\n<br/>\n<br/>\nRegards,<br/> \nWitek<br/>\n<br/>\n#<br/>\n# Automatically generated make config: don't edit<br/>\n# Linux/i386 3.0.0-rc1 Kernel Configuration<br/>\n#<br/>\n# CONFIG_64BIT is not set<br/>\nCONFIG_X86_32=y<br/>\n# CONFIG_X86_64 is not set<br/>\nCONFIG_X86=y<br/>\nCONFIG_INSTRUCTION_DECODER=y<br/>
\nCONFIG_OUTPUT_FORMAT="elf32-i386"<br/>\nCONFIG_ARCH_DEFCONFIG=
"arch/x86/configs/i386_defconfig"\nCONFIG_GENERIC_CMOS_UPDATE=y<br/
>\nCONFIG_CLOCKSOURCE_WATCHDOG=y<br/>\nCONFIG_GENERIC_CLOCKEVENTS=y<
br/>\nCONFIG_LOCKDEP_SUPPORT=y<br/>\nCONFIG_STACKTRACE_SUPPORT=y<br/
>\nCONFIG_HAVE_LATENCYTOP_SUPPORT=y<br/>\nCONFIG_MMU=y<br/>\nCONF
IG_ZONE_DMA=y<br/>\n# CONFIG_NEED_DMA_MAP_STATE is not set<br/>\nCONFIG_NEED_SG_DMA_LENGTH=y<br/>\nCONFIG_GENERIC_ISA_DMA=y
<br/>\nCONFIG_GENERIC_IOMAP=y<br/>\nCONFIG_GENERIC_BUG=y<br/>\
nCONFIG_GENERIC_HWEIGHT=y<br/>\nCONFIG_ARCH_MAY_HAVE_PC_FDC=y<br/>\n
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set<br/>\nCONFIG_RWSEM_");
(I'm sure the formatting will be wrecked, but it gives you an
idea of what I mean by a large tooltip)
...at least on my 1024x768 display, it's not hard to position a window so that fltk puts that under the cursor unnecessarily,
and it flashes and can't be read.
And then there's the question of what makes sense to do when it is so large that you just can't avoid placing it under the cursor or shifting part of it off screen... | |
| |
| #2 | manolo
07:16 May 31, 2011 |
| I suggest the attached tooltip.patch to fix this STR.
Does the OP agree ? | |
| |
| #3 | corvid
07:39 May 31, 2011 |
| I don't notice a change in behaviour with this patch. | |
| |
| #4 | corvid
08:00 May 31, 2011 |
| Wait, it _is_ an improvement now when I put a big tooltip into a fltk test/ program, as opposed to testing in Dillo. Hmm... | |
| |
| #5 | corvid
11:58 May 31, 2011 |
| So far as I can tell, my problem is that, since Dillo doesn't have separate FLTK widgets for everything that has a tooltip (e.g., links), it calls enter_area() and leave() on its own. The patch helps when the tooltip window is entered, but then Dillo is receiving leave and enter events. | |
| |
| #6 | corvid
11:59 May 31, 2011 |
| Oh, BTW, would your patch be a problem if the tooltip covered the entire screen? | |
| |
| #7 | manolo
12:25 May 31, 2011 |
| I don't think the patch in itself would create a problem if the tooltip covers the entire screen, but it may not solve possible problems arising then. The tooltip would fill all the screen, so I might be difficult to get rid of it. But, isn't this scenario very unrealistic? | |
| |
| #8 | corvid
13:06 May 31, 2011 |
| I found myself thinking about it when, even though Fl_Tooltip would prefer to wrap at 400, fl_expand_text can't do that if you have, say, a long URL in the string. I imagine it's a situation you could get into now and then on handhelds, at least. | |
| |
| #9 | matt
12:42 Jun 03, 2011 |
| As a general remark: a tooltip that contains more than a screens worth of content is no longer a tooltip. There are better ways of displaying such a huge amount of information. Also, a link that is more than 40 characters could be abbreviated to show the first and last 18 characters, separated by an elipsis. The full path could then still be made available by right-clicking into a context menu and sending the URL to the copy/paste buffer.
For example:
"http://www.google.de/sear...esc=&ei=_zjpTdXkJsnMswaqtKHoCg" | |
| |
| #10 | matt
12:55 Jun 03, 2011 |
| Corvid: could you please check if the submitted patch works for you. If I don't hear from you until Sunday noon CET, I will mark the STR as fixed. Thanks. | |
| |
| #11 | corvid
13:21 Jun 03, 2011 |
| We show whatever is in the title attribute of a tag as a tooltip since that's conventional behaviour, and we can trim it down, look for the end of a unicode character, and append an ellipsis now that we've found that there can be an issue with long ones.
As for the patch, since it doesn't make a difference with how Dillo handles tooltips, I have no opinion on whether you apply it. | |
| |
| #12 | matt
14:51 Jun 03, 2011 |
| Thanks. I'll see if I can come up with something else... . | |
| |
| #13 | matt
07:36 Jun 08, 2011 |
| Moving this to the next release. I can see that in extreme cases there can be an issue. In the normal use case, tooltips should work fine. | |
| |
| #14 | cand
01:27 Nov 22, 2014 |
| I'm seeing this bug with 1.3.3 in Fifth. Some web pages create huge tooltips (github, looking at you), larger than my screen, which flicker briefly and disappear.
The patch fixes my simple test case (attached, bigtip.cpp), haven't tested yet in Fifth.
Assuming it also fixes the bigger app, is anyone opposed to this patch in 1.3? | |
| |
| #15 | AlbrechtS
03:31 Nov 22, 2014 |
| Patch looks good, and behavior is much better (tested under Linux in a VM with local and remote (Cygwin) X server).
+1 | |
| |
| #16 | cand
03:36 Nov 22, 2014 |
| After testing in Fifth, yes it fixes the flicker, but introduces another issue: when the tooltip covers the entire screen, you cannot dismiss the tooltip! | |
| |
| #17 | AlbrechtS
03:42 Nov 22, 2014 |
| When I tested with your bigtip.cpp file I found that it was sometimes difficult to dismiss the tooltip. However it worked like this:
(1) click on the tooltip window: it disappears (but would come back soon)
(2) click on the main window: tooltip does NOT come back
Does this work in Fifth with the full screen tooltip you mentioned?
BTW: Fifth is an interesting project! | |
| |
| #18 | cand
03:50 Nov 22, 2014 |
| Attaching a patch that combines the previous one + hides the tooltip on keypress and mouse press. | |
| |
| #19 | cand
03:54 Nov 22, 2014 |
| With a fullscreen tooltip, you cannot click on any other window, as it covers the entire screen, alt-tab does nothing, and so forth. Clicking on the tooltip itself did not dismiss it. | |
| |
| #20 | cand
01:50 Nov 27, 2014 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
