Community
Participate
Working Groups
I20070313-1051 Trees and Tables with a PaintItem listener installed do not show tooltips when hovering over clipped items. To reproduce, run the ControlExample, install the PaintItem listener and expand the Tree / resize a Table header.
Duplicate/Related to Bug 174675
We should decide early in 3.4 whether this feature will be supplied by SWT (e.g. by using the EraseItem and PaintItem callbacks with different background colors to draw in the tooltip), or whether JFace has to offer support for it.
Given that tree hover help doesn't happen on every platform, then JFace should not support it.
This will likely need new API, and it would be good to have the SWT implementation ready before the new JFace support for owner draw label providers is released (bug 188333).
>Given that tree hover help doesn't happen on every platform, then JFace should >not support it.
Steve, JFace isn't supporting a fix to the lost rollover on win32. They're just creating an extensible owner-draw framework (your favorite word), so that multiple plug-ins/sources can contribute to the painting of a common Tree. So the only concern from that point of view is that the native behavior on win32 degrades with owner draw. Couldn't the same API be used for this fix? Listeners receives a paint callback with a GC and some dimensions. It just happens that the GC is on a popup shell instead of the actual tree.
my bad, in comment 2 MK hints at jface fixing the bug if SWT wouldn't.
(In reply to comment #5) Yes, but JFace will add API that clients have to implement to get owner draw support. If you want to make the hover help tooltips look exactly the same as native tooltips for non-owner-draw trees/tables, then you need to know what part of an owner-drawn label should be considered as "text" (should go into the tooltip) and what part should be considered as "image" (not in tooltip). This may not look like additional API in SWT due to bug 81334, but will probably influence the new JFace API. I just wanted to make affected parties aware of this potential dependency.
On Vista, the image is part of the tool tip.
I'm hoping to fix this the same way that Randy suggested, however, there may be unforseen problems with this approach.
(In reply to comment #9) > On Vista, the image is part of the tool tip. An even better and easier approach than faking native-looking tooltips on XP and Vista would be to support the Vista-style tooltips on all platforms for owner-drawn items. After all, the items are not really native any more, so why should their hover help be? This would be helpful on all platforms and would probably not need new API just for WinXP emulation.
> An even better and easier approach than faking native-looking tooltips on XP > and Vista would be to support the Vista-style tooltips on all platforms for > owner-drawn items. After all, the items are not really native any more, so why > should their hover help be? Not to agree or disagree, but can we agree on the terminology? "Tooltips" to me mean displaying *additional* information that is: - normally not visible - appears after the hover event/threshold - positioned outside of the thing it is describing To avoid confusion, can we use "Rollover" to mean: - the display of clipped/truncated (but at other times plainly visible) information - something immediately displayed (on mouse over) - and in the same location as the "shortened form" Since jface recently implemented tooltip "emulation" for individual items or even "cells", both of these terms are valid when describing a treeitem. It also reminds you of the subtle details that make this hard, and maybe only solvable by the SWT team. If a popup shell is used, it basically has to be a ghost so that moves, clicks, hovers, etc. are routed to the underlying tree. We tried making rollovers work in the GEF palette a while back, and a simple, cross-platform approach wasn't found. Mouse capture was risky and only reliable (for SWT clients) on win32. Since the palette is a black box, a compromise was OK there. See Veronika's comments in bug 19430.
> If a popup shell is used, it basically has to be a ghost so > that moves, clicks, hovers, etc. are routed to the underlying tree. > > [..] Mouse capture was risky [..] I don't think full capture is necessary. It would be enough to listen for MouseDown events, dispose the rollover tooltip, and Display#post(..) the MouseDown event again. I hacked this into the QuickAccess dialog and it worked fine.
*** Bug 204976 has been marked as a duplicate of this bug. ***
Could this problem please be tackled for 3.4? This is a major usability/productivity impediment for all owner-drawn widgets.
(In reply to comment #13) > > If a popup shell is used, it basically has to be a ghost so > > that moves, clicks, hovers, etc. are routed to the underlying tree. > > > > [..] Mouse capture was risky [..] > > I don't think full capture is necessary. It would be enough to listen for > MouseDown events, dispose the rollover tooltip, and Display#post(..) the > MouseDown event again. I hacked this into the QuickAccess dialog and it worked > fine. > JFace Tooltips will provide this feature as I can resolve bug #195137. On OS-X there's a problem with hiding a Shell if you study the code. I didn't had time to file an issue against SWT.
Ok, but when this bug gets fixed, we will need to be on the look out for 2 tooltips. Also, JFace tooltips have the wrong look on Vista (not sure right now how to get you the right one).
Fixed > 20071126
Thanks a lot for fixing this, Steve! I filed bugs 211194 thru 211197 for a few follow-up issues.
I expected there to be a few problems. Thanks for entering the bugs.
*** Bug 174675 has been marked as a duplicate of this bug. ***
