Bugzilla – Full Text Bug Listing
|
Description
Karsten ...
Created attachment 183246 [details]
Snippet demonstrating tool tip behaviour
This might also be related to changes in SWT - actually, when using SWT version 3.5 together with a 3.6 JFace, hovering the tool tip works; after exchanging the 3.5 SWT for a 3.6 version, it does not. I don't remember any changes in JFace-Tooltip - naturally it could be that we are using an SWT-API in appropriately. Does it work if you remove the ToolTip.NO_RECREATE? No, unfortunately it doesn't; without ToolTip.NO_RECREATE set, the tool tip cannot be hovered either (which, as far as I understand, should be the expected behaviour). As mentioned in comment #2, after some experimenting I assume there might have been changes to SWT itself between versions 3.5 and 3.6 preventing tool tip hovering on Linux-GTK. On Windows, this works fine though. Please, provide a SWT only snippet that reproduces the problem. ToolTip.NO_RECREATE is not SWT and we do not know what it does. Thank you. (In reply to comment #5) > Please, provide a SWT only snippet that reproduces the problem. > ToolTip.NO_RECREATE is not SWT and we do not know what it does. > Thank you. I would expect that you can easily debug this using the given small snippet. The fact that it is working on other platforms but not Linux-GTK is a good indication that SWT is involved. A wild guess is that the fix for bug 305433 caused the regression. Ping. Silenio, Can you test this ? (this works on my machine, gtk 2.16) Note that Dani has pointed out this problem can be related to bug 305433. I cannot reproduce this in my machine either (RedHat 6 with GTK 2.18). Bogdan, do you have GTK 2.22 to try this? Tried on my notebook at home with GTK+ 2.20, looks good here on I20101205-2000. Karsten, what OS and WM do you have exactly? Default Ubuntu 10.10, i.e. Gnome 2.32.0, GTK+ 2.22.0, Compiz 0.8.6. (Doesn't work with Compiz deactivated either.) As far as I can tell, NO_RECREATE is working as intended. This is on GTK3.22, Fedora 25, and Eclipse/SWT Oxygen. I can reproduce this with the given snippet on Ubunutu 16.04, GTK 3.18.9, SWT 3.106.0.v20170526-0827 and JFace 3.13.0.v20170503-1507. It's impossible to move the mouse cursor over the tooltip: the tooltip closes before the mouse gets there. As far as my debugging showed: * the tooltip's shells gets a SWT.MouseExit event with coordinates inside the shell's bounds. * TooltipHideListener from org.eclipse.jface.windows.ToolTip then checks those coordinates against an artificially inset rectangle (5px inset). * TooltipHideListener closes the tooltip (so evidently the coordinates were not inside the smaller inset rectangle). Removing the artifical inset in TooltipHideListener resolves the problem. Two problems here: 1. SWT: why does the tooltip shell get an SWT.MouseExit event when the mouse cursor moves _into_ the shell? (Appears to occur only on GTK; no such problem on MacOS). 2. JFace: what's the purpose of that artifical inset? (In reply to Karsten ... from comment #1) > Created attachment 183246 [details] > Snippet demonstrating tool tip behaviour I can also not enter the tooltip under Ubuntu. Removing the 5 pixels inset in JFace solves the issue for me. I upload a Gerrit soon. New Gerrit change created: https://git.eclipse.org/r/99561 Gerrit change https://git.eclipse.org/r/99561 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a5a05e14cc41c425a4c14dc827363d56cfec4703 If i remember correctly this insets have been necessary to get mouse-exits when you move the mouse out very fast on (mac or win32 i don't recall which platform it has been). As I have not seen a reply to Dani's request on gerrit I assume you have tested this change thoroughly on none linux gtk platforms. (In reply to Thomas Schindl from comment #19) > If i remember correctly this insets have been necessary to get mouse-exits > when you move the mouse out very fast on (mac or win32 i don't recall which > platform it has been). > > As I have not seen a reply to Dani's request on gerrit I assume you have > tested this change thoroughly on none linux gtk platforms. Thomas from the Egit team tested it in Windows and Mac but more testing is welcome. (In reply to Lars Vogel from comment #20) > (In reply to Thomas Schindl from comment #19) > > If i remember correctly this insets have been necessary to get mouse-exits > > when you move the mouse out very fast on (mac or win32 i don't recall which > > platform it has been). > > > > As I have not seen a reply to Dani's request on gerrit I assume you have > > tested this change thoroughly on none linux gtk platforms. > > Thomas from the Egit team tested it in Windows and Mac but more testing is > welcome. I said I had tested the use case in EGit, and it worked all right on all three platforms. I did _not_ do more testing with other kinds of tooltip contents, nor with RECREATE tooltips. EGit uses this only with a NO_RECREATE tooltip. In any case, insetting by an arbitrary amount of pixels doesn't sound like a proper fix for "moving the mouse out very fast". But with Thomas Schindl's hint, I now see one minor difference in behavior for NO_RECREATE tooltips on Windows 7: when you move the mouse out of the tooltip *slowly* back over the control on which the tooltip is attached, it isn't closed. If you move the mouse pointer out of the tooltip anywhere else, it is closed. (And if you move the mouse out of the control on which the tooltip is attached, it is also closed.)
This slight behavioral difference can be seen with EGit nightly comparing the behavior of the new "+" popup in the staging viewer (on selected files in the unstaged section) -- doesn't use the inset -- with the behavior of the tooltip on the "Status" column in the "Rebase interactive" view (if you are in an interactive rebase, of course).
For NO_RECREATE tooltips, that behavior change seems to be fine. I do not know what the effects would be for a RECREATE tooltip.
I do not see any behavior change on MacOS. Just for fun I also tested on RHEL 7.2, GTK 2.24.28: no behavior change. (Except, of course, that you can hover over the tooltip in the staging view, while you cannot hover over the one in the rebase interactive view.)
If you want to test a RECREATE tooltip: I had a hard time finding one. There _is_ one in the "Customize Perspective" dialog, "Action set availability", first column ("Avilable action sets"). Pops up when hovering over an action set name. (Off-topic: and frankly said, that tooltip disappearing and re-appearing when the mouse moves within the same line is annoying.)
New Gerrit change created: https://git.eclipse.org/r/99870 Gerrit change https://git.eclipse.org/r/99870 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=431c069029e98873c88cc8490569a9a22b68bdd2 (In reply to Eclipse Genie from comment #24) > Gerrit change https://git.eclipse.org/r/99870 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=431c069029e98873c88cc8490569a9a22b68bdd2 The changes causes a regression on Windows 7. Using th snippet from comment 1 the following scenario is broken: 1. Move mouse to get the hover 2. Move into hover 3. Move back to text ==> hover stays ==> BUG (In reply to Dani Megert from comment #25) > (In reply to Eclipse Genie from comment #24) > > Gerrit change https://git.eclipse.org/r/99870 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=431c069029e98873c88cc8490569a9a22b68bdd2 > > The changes causes a regression on Windows 7. Using th snippet from comment > 1 the following scenario is broken: > 1. Move mouse to get the hover > 2. Move into hover > 3. Move back to text > ==> hover stays ==> BUG Sorry, my bad! That's actually the correct behavior and matches what we do in the Java editor. Will revert the revert. New Gerrit change created: https://git.eclipse.org/r/99925 Gerrit change https://git.eclipse.org/r/99925 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0ebfd064870cabf306cb2cd252075670075853a8 (In reply to Dani Megert from comment #26) > Sorry, my bad! That's actually the correct behavior and matches what we do > in the Java editor. Good to hear, I proceed with the downport. Gerrit change https://git.eclipse.org/r/101483 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=36224d3f8a411456721b9a788702b591adfbd20b A big thanks to Thomas Wolf for providing the implementation via Egit and doing the testing. To reflect that I assign the bug to him. |