Community
Participate
Working Groups
Created attachment 254401 [details] Spelling Preference Page - Screenshot 1 Please see attached screenshots of the preference page for Spelling. Something is causing large vertical empty space. Using Mars RC3 on XUbuntu.
Created attachment 254402 [details] Spelling Preference Page - Screenshot 2
GTK2 or GTK3? Which version exact? Which GTK theme? Does it work with Adwaita (or any other theme)?
(In reply to Andrey Loskutov from comment #2) > GTK2 or GTK3? GTK3 > Which version exact? libgtk-3-0: 3.10.8-0ubuntu1.4 > Which GTK theme? Albatross, from shimmer-themes 1.7.3-0ubuntu1 > Does it work with Adwaita (or any other theme)? I tried with these ones, they all had the same result: Adwaita Bluebird Clearlooks Orion I also tried with "SWT_GTK3=0" set and the GUI looks fine. More screenshots coming if that helps.
Created attachment 254529 [details] Spelling Preference Page, GTK2
Created attachment 254530 [details] Adwaita theme with narrow window
Created attachment 254531 [details] Adwaita theme with wider window I added the narrow/wider window screenshots to show that by making the window a little narrower it leads to significantly increased whitespace between controls.
I have reproduced this on Neon M1 with Fedora 22 and Gtk3.16.6.
If you re-size the window to make it larger (i.e. grab one of the corners with the mouse and drag), it fixes this issue. This seems to be a duplicate of bug 471094, as far as I can tell. I will mark it as a duplicate for now. *** This bug has been marked as a duplicate of bug 471094 ***
(In reply to Eric Williams from comment #8) > If you re-size the window to make it larger (i.e. grab one of the corners > with the mouse and drag), it fixes this issue. This seems to be a duplicate > of bug 471094, as far as I can tell. I will mark it as a duplicate for now. > > *** This bug has been marked as a duplicate of bug 471094 *** Hi Eric. A lot of things are "fixed" when triggering some sort of relayout or repaint but it doesn't mean it's the same cause of problem. Here the bugs have different symptoms (large vertical scrolling on GTK3 vs shrunk on *both* GTKs) and could have different cause. I think it's better to leave it open until one is fixed then we can test if it fixes both. Otherwise, it's easy to forget and not test the one that was closed.
(In reply to Marc-Andre Laperle from comment #9) > Hi Eric. A lot of things are "fixed" when triggering some sort of relayout > or repaint but it doesn't mean it's the same cause of problem. Here the bugs > have different symptoms (large vertical scrolling on GTK3 vs shrunk on > *both* GTKs) and could have different cause. I think it's better to leave it > open until one is fixed then we can test if it fixes both. Otherwise, it's > easy to forget and not test the one that was closed. That's a good point. I'll keep them open until further investigation. As a side note, I'm looking into this bug at the moment and seems it's getting crazy initial y values for the size of the preferences box. When you re-size the window, the y value is updated accordingly and displays correctly.
(In reply to Eric Williams from comment #10) > That's a good point. I'll keep them open until further investigation. > > As a side note, I'm looking into this bug at the moment and seems it's > getting crazy initial y values for the size of the preferences box. When you > re-size the window, the y value is updated accordingly and displays > correctly. I wonder if some of these bugs are due to what I would call a "cached computeSize" which can happen when size requests are cached on the GTK side. See bug 445801 and https://bugzilla.gnome.org/show_bug.cgi?id=753116 I'll try forcing the cache to clear by calling gtk_widget_queue_resize when computSize(foo, foo, true) and see if some of those bugs are fixed, just as an hint.
(In reply to Marc-Andre Laperle from comment #11) > I wonder if some of these bugs are due to what I would call a "cached > computeSize" which can happen when size requests are cached on the GTK side. > See bug 445801 and https://bugzilla.gnome.org/show_bug.cgi?id=753116 > > I'll try forcing the cache to clear by calling gtk_widget_queue_resize when > computSize(foo, foo, true) and see if some of those bugs are fixed, just as > an hint. Interesting, will give it a try. So far I've confirmed that Control.computeSize() is returning some odd values in Gtk3 -- this seems to be the root of the issue for this specific case.
(In reply to Eric Williams from comment #12) > Interesting, will give it a try. So far I've confirmed that > Control.computeSize() is returning some odd values in Gtk3 -- this seems to > be the root of the issue for this specific case. Sounds a bit like bug 436655. In fact, if I apply the patch from https://bugs.eclipse.org/bugs/show_bug.cgi?id=436655#c10 then the Spelling page displays correctly. We still need to make a snippet for contributing this patch to GTK and also need a workaround in SWT for old GTK versions.
(In reply to Marc-Andre Laperle from comment #11) > I'll try forcing the cache to clear by calling gtk_widget_queue_resize when > computSize(foo, foo, true) and see if some of those bugs are fixed, just as > an hint. Just for the record, that experiment didn't go so well: I couldn't open the spelling page at all anymore!
(In reply to Marc-Andre Laperle from comment #14) > (In reply to Marc-Andre Laperle from comment #11) > > I'll try forcing the cache to clear by calling gtk_widget_queue_resize when > > computSize(foo, foo, true) and see if some of those bugs are fixed, just as > > an hint. > > Just for the record, that experiment didn't go so well: I couldn't open the > spelling page at all anymore! Does the patch for frame.c (native Gtk) still fix the issue? If so, it's possible the bug lies some where in Group.
(In reply to Eric Williams from comment #15) > Does the patch for frame.c (native Gtk) still fix the issue? If so, it's > possible the bug lies some where in Group. Yes it does. I thought it was pretty clear with this patch that the bug is in GTK and not in SWT. But I'd have to double check the call stack in SWT. I can't verify right now but I think it might be a case where SWT requests (0, 0) for size which GTK doesn't handle properly. We could clamp the values in SWT to something that GTK will like but it's not ideal and the minimum could change in GTK at any time So the minimum could be width = Math.Min(width, 1 + 2 * LABEL_PAD + 2 * LABEL_SIDE_PAD) or perhaps something based on preferred size?
(In reply to Marc-Andre Laperle from comment #16) > Yes it does. I thought it was pretty clear with this patch that the bug is > in GTK and not in SWT. > > But I'd have to double check the call stack in SWT. I can't verify right now > but I think it might be a case where SWT requests (0, 0) for size which GTK > doesn't handle properly. We could clamp the values in SWT to something that > GTK will like but it's not ideal and the minimum could change in GTK at any > time This would be the root cause, yes, which may be difficult to pin down. With some further investigation I've discovered the inflated height/y values coming from the composite's GridLayoutData. When I do a check for large height values (i.e. any value greater than the height of the monitor) and flush the layout data, the frames draw properly in the window but the window it self still has a very large area to scroll down to. I will investigate more.
(In reply to Eric Williams from comment #17) > I will investigate more. The root cause of the issue is a call to gtk_widget_get_allocation() in Scrollable, in the method getClientArea(). The height values returned here can be anywhere from 30,000px to 2,000,000px.
(In reply to Eric Williams from comment #18) > (In reply to Eric Williams from comment #17) > > I will investigate more. > > The root cause of the issue is a call to gtk_widget_get_allocation() in > Scrollable, in the method getClientArea(). The height values returned here > can be anywhere from 30,000px to 2,000,000px. Do you know why it returns such values? I think it's worth investigating as it could affect other widgets (and other GTK applications?).
(In reply to Marc-Andre Laperle from comment #19) > Do you know why it returns such values? I think it's worth investigating as > it could affect other widgets (and other GTK applications?). I don't know why, I am looking into it at the moment. To make matters a little more complicated, it seems this issue doesn't reproduce all the time. For example, when running Eclipse, I can get it to reproduce maybe 2-3 times out of 10. Other times the correct values are fetched and the bug doesn't reproduce at all.
In addition to the large gaps, I've observed that when this bug is present, the OK and Cancel buttons disappear intermittently as well. So far I've been able to somewhat make the behaviour better, but it's a temporary workaround at best. What I've managed to do is check for height sizes and limit the groups/composites/controls from eating up all of the screen space by capping their height to the height of the shell. The user will still have to re-size the window occasionally if the groups don't layout properly (which I suspect is due to a different bug), but at least all the buttons are reachable, and the OK and Cancel buttons don't disappear. I'll continue investigating to see if there's a better solution until this gets fixed on the native Gtk end.
(In reply to Eric Williams from comment #21) > I'll continue investigating to see if there's a better solution until this > gets fixed on the native Gtk end. On my end, I've made a snippet for GTK and opened a bug with a patch: https://bugzilla.gnome.org/show_bug.cgi?id=754976 I'll check if the issue can be worked around in a better way in SWT (aside from clamping the height). I think setting the Group to a minimum width (8?) might be something worth looking into.
New Gerrit change created: https://git.eclipse.org/r/55819
(In reply to Marc-Andre Laperle from comment #22) > I think setting the Group to a minimum width (8?) > might be something worth looking into. (In reply to Eclipse Genie from comment #23) > New Gerrit change created: https://git.eclipse.org/r/55819 I tried that approach and it seems to work perfectly. The minimum actually has to be 12 because we have to compensate for - In gtk_frame_size_allocate: 2 * LABEL_PAD + 2 * LABEL_SIDE_PAD - In gtk_frame_real_compute_child_allocation: 2 * LABEL_PAD + 2 * LABEL_SIDE_PAD Where LABEL_SIDE_PAD = 2 Where LABEL_PAD = 1
(In reply to Marc-Andre Laperle from comment #24) > The minimum actually has to be 12 because we have to compensate for > - In gtk_frame_size_allocate: 2 * LABEL_PAD + 2 * LABEL_SIDE_PAD > - In gtk_frame_real_compute_child_allocation: 2 * LABEL_PAD + 2 * > LABEL_SIDE_PAD > Where LABEL_SIDE_PAD = 2 > Where LABEL_PAD = 1 This fixes the issue! A much better workaround than clamping the height manually. I haven't been able to compile Gtk recently but having read the GtkFrame source code, there shouldn't be any issues with them accepting your patch on the native side.
*** Bug 436655 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/55819 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=4335c7506dde2f0b51d1de8828f57609062b8563
Last patch is pretty good. Pushed.
*** Bug 476471 has been marked as a duplicate of this bug. ***
