Community
Participate
Working Groups
Created attachment 281794 [details] Video of text hover behaviour with GDK_SCALE=2 With GDK_SCALE set to 2, the text hover tooltip in the source editor frequently appears in the wrong location. On first use it will be in the right location. After that, on every subsequent use (including pressing F2) it appears to double its location until it moves offscreen. Occasionally the tooltip will appear in the right location again. In debug view, the tooltip displaying values of variables works fine, until it gets mouse focus. After that it is only a few pixels high and remains in this state until eclipse is restarted. The bug affects Eclipse version 4.12 as well as 4.15.0M1 and 4.15.0M2 (and presumably everything in between). GTK version is 3.24.5-1 The attached video was recorded in the following conditions Resolution: 3840x2160 Display scaling: 1.5 Eclipse 2019-06 (4.12) launched with: GDK_SCALE=2 GDK_DPI_SCALE=0.5 ./eclipse Keypresses displayed with "Screenkey" Even the recording software (SimpleScreenRecorder) has issues with UI scale, hence the black rectangle in the top right corner.
I got the same problem on Gnome3/FreeBSD-12.1 with: gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "{'Gdk/WindowScalingFactor': <2> , 'Gtk/ShellShowsAppMenu': <1> }" and this patch fixed for me: cat files/patch-org_eclipse_swt_widgets_Shell.java --- org/eclipse/swt/widgets/Shell.java.orig 2019-12-09 22:30:06 UTC +++ org/eclipse/swt/widgets/Shell.java @@ -1472,6 +1472,8 @@ long gtk_button_press_event (long widget, long event) long gtk_configure_event (long widget, long event) { int [] x = new int [1], y = new int [1]; GTK.gtk_window_get_position (shellHandle, x, y); + int scale = GTK.gtk_widget_get_scale_factor(shellHandle); + x[0] /= scale; y[0] /= scale; if (!isVisible ()) { return 0; //We shouldn't handle move/resize events if shell is hidden. @@ -3188,6 +3190,8 @@ Rectangle getBoundsInPixels () { int [] x = new int [1], y = new int [1]; if ((state & Widget.DISPOSE_SENT) == 0) { GTK.gtk_window_get_position (shellHandle, x, y); + int scale = GTK.gtk_widget_get_scale_factor(shellHandle); + x[0] /= scale; y[0] /= scale; } else { if (GTK.GTK4) { GDK.gdk_surface_get_root_origin(GTK.gtk_widget_get_surface(shellHandle), x, y);
(In reply to Wenhui Huang from comment #1) > I got the same problem on Gnome3/FreeBSD-12.1 with: > > gsettings set org.gnome.settings-daemon.plugins.xsettings overrides > "{'Gdk/WindowScalingFactor': <2> , 'Gtk/ShellShowsAppMenu': <1> }" > > and this patch fixed for me: Hi Wenhui, thanks for the patch proposal. Could you please sign ECA agreement and push the patch to Gerrit? See https://wiki.eclipse.org/Platform/How_to_Contribute
I have the same issue. And I think it is rather critical one, because it heavily impacts the usability of the Eclipse IDE in general. Asking to provide a PR/change/patch through the "proper" channels of a project is fine in general for me. But in that case the instructions how to do so should be accurate and understandable for newcomers. Which they are not for SWT. Anyway, I tried the proposed patch and could see a difference in behavior. For me it did not fix the issue. I played around a bit with the code, I saw changes in behavior (so I did modify the right code) but couldn't get the desired behavior.
(In reply to Jens Reimann from comment #3) > I have the same issue. And I think it is rather critical one, because it > heavily impacts the usability of the Eclipse IDE in general. Patches are welcome (via proper channels). > Asking to provide a PR/change/patch through the "proper" channels of a > project is fine in general for me. It is not a question of "fine or not", it is as simple as we can't accept contributions without ECA signed, and we also prefer Gerrit because it tests for us basic things and we can save time by using a proper review tool for reviews. > But in that case the instructions how to > do so should be accurate and understandable for newcomers. Which they are > not for SWT. It is a wiki, and we all part of the community. Please feel free to improve the wiki if you see problems, or at least open a bug describing what is not working for you to contribute to SWT.
(In reply to Andrey Loskutov from comment #4) > (In reply to Jens Reimann from comment #3) > > I have the same issue. And I think it is rather critical one, because it > > heavily impacts the usability of the Eclipse IDE in general. > > Patches are welcome (via proper channels). I am sorry, but I cannot patch out all the issues of my favorite IDE before starting my actual work. And in this case, I really tried. > > > Asking to provide a PR/change/patch through the "proper" channels of a > > project is fine in general for me. > > It is not a question of "fine or not", it is as simple as we can't accept > contributions without ECA signed, and we also prefer Gerrit because it tests > for us basic things and we can save time by using a proper review tool for > reviews. I think it is matter of making it easier for people to help fix stuff. Pointing to an outdated, very broad and wrong documentation doesn't help. Asking to fiddle with Gerrit for a change that small will only scare people away. And I do understand that accepting an ECA is essential. > > > But in that case the instructions how to > > do so should be accurate and understandable for newcomers. Which they are > > not for SWT. > > It is a wiki, and we all part of the community. Please feel free to improve > the wiki if you see problems, or at least open a bug describing what is not > working for you to contribute to SWT. It's not only a Wiki, but also a web page: https://www.eclipse.org/swt/fixbugs.php … And you have an open change for that in gerrit already. All that I am trying to say here is: this is a super important issue, which makes your whole IDE experience totally miserable. I tried to fix it, and had to fix the setup instructions first, before I eventually came to the point where I could try to fix the original issue. That many hurdles doesn't win you any contributors. Doesn't any bugs fixed, and people will start to look elsewhere for a working solution.
(In reply to Jens Reimann from comment #5) > > It's not only a Wiki, but also a web page: > https://www.eclipse.org/swt/fixbugs.php … And you have an open change for > that in gerrit already. > Thanks for the patch. Adjusted anonymous links, egit instructions, https links and progit book url too in later commits.
