Community
Participate
Working Groups
Created attachment 277850 [details] Screenshot on GTK 3.22 / RHEL 7.4 This is similar to bug 542867, and probably a regression from 539367 (have not bisected yet). We see that this regression appears after moving from 4.9 to 4.10, and also 4.11 head has the same issue. The code below shows last character slightly cut off on Adwaita theme, and a bigger cut off on Clearlooks-Phenix theme, on GTK 3.22 / RHEL 7.4. import org.eclipse.swt.SWT; import org.eclipse.swt.graphics.GC; import org.eclipse.swt.graphics.Point; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.layout.RowLayout; import org.eclipse.swt.widgets.Combo; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class ComboCutOff { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setSize(600, 200); shell.setLayout(new FillLayout(SWT.HORIZONTAL)); Composite root = new Composite(shell, SWT.NONE); root.setLayout(new RowLayout(SWT.HORIZONTAL)); Combo combo = new Combo(root, SWT.READ_ONLY); combo.setItems("AAA", "AA", "A"); combo.select(0); Combo combo2 = new Combo(root, SWT.READ_ONLY); combo2.setItems("YYY"); combo2.select(0); Combo combo3 = new Combo(root, SWT.READ_ONLY); combo3.setItems("XXX"); combo3.select(0); Combo combo4 = new Combo(root, SWT.READ_ONLY); combo4.setItems("WWW"); combo4.select(0); Combo combo5 = new Combo(root, SWT.READ_ONLY); combo5.setItems("WWW"); combo5.select(0); shell.open(); // Workaround is to add a bit more pixels GC gc = new GC(shell); Point textExtent = gc.textExtent("W"); Point size = combo5.getSize(); size.x = size.x + textExtent.x; combo5.setSize(size); while (!shell.isDisposed()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } }
Reverting changes from bug 542867, bug 540165, bug 542926 do not help, probably bug 539367?
Hmm I can't reproduce this on my machine. GTK3.20, 3.22, and 3.24 all look fine. Could it possibly be some desktop environment difference? (Doesn't seem likely) And before you ask, yes I uncommented the workaround. :)
(In reply to Eric Williams from comment #2) > And before you ask, yes I uncommented the workaround. :) Err, uncommented -> commented out
Created attachment 277853 [details] my font settings (In reply to Eric Williams from comment #2) > Hmm I can't reproduce this on my machine. GTK3.20, 3.22, and 3.24 all look > fine. Could it possibly be some desktop environment difference? (Doesn't > seem likely) > > And before you ask, yes I uncommented the workaround. :) I imagine this can be DPI/font related, because it looks like the width is calculated based on the text content, and this calculation just misses one "character width" or less. I have "force 96 DPI" with AA on and exclude range for 8-15 sizes. But since this is also much stronger with a different theme, could be also some padding problem. Attached are my font settings. Interestingly, it seems they aren't used by pure SWT example - any idea where the default fonts are coming from in pure SWT?
(In reply to Andrey Loskutov from comment #4) > Created attachment 277853 [details] > my font settings > > (In reply to Eric Williams from comment #2) > > Hmm I can't reproduce this on my machine. GTK3.20, 3.22, and 3.24 all look > > fine. Could it possibly be some desktop environment difference? (Doesn't > > seem likely) > > > > And before you ask, yes I uncommented the workaround. :) > > I imagine this can be DPI/font related, because it looks like the width is > calculated based on the text content, and this calculation just misses one > "character width" or less. I have "force 96 DPI" with AA on and exclude > range for 8-15 sizes. But since this is also much stronger with a different > theme, could be also some padding problem. Attached are my font settings. > Interestingly, it seems they aren't used by pure SWT example - any idea > where the default fonts are coming from in pure SWT? The font settings you attached, where is this window? GNOME tweak tools or is it something else? As for fonts in SWT -- they come from GtkStyleContext. So these should be coming from your theme/system settings, unless I am misunderstanding something or GtkStyleContext is broken somehow (wouldn't be the first time). If you have default font settings on your machine, does the bug still reproduce?
Odd, in org.eclipse.swt.widgets.Combo.computeNativeSize(long, int, int, boolean) I see: int [] xpad = new int[1]; if (textRenderer != 0) GTK.gtk_cell_renderer_get_padding(textRenderer, xpad, null); Point nativeSize = super.computeNativeSize(h, wHint, hHint, changed); nativeSize.x += xpad[0] * 2; We specify padding of 4px in our theme, however xpad[0] is 2px when I execute the snippet from the description. If I bump the native size manually to twice the padding we specify, I see similar-to-Adwaita behaviour.
The GtkComboBox with an entry has two elements, a text field and a GtkIcon. Via theme .css the nodes on which properties can be set are: combobox ├── box.linked │ ├── entry.combo │ ╰── button.combo │ ╰── box │ ╰── arrow ╰── window.popup See: https://developer.gnome.org/gtk3/stable/GtkComboBox.html In our theme we specify: combobox entry.combo, combobox button.combo { padding: 4px; } In Combo.computeNativeSize only the padding of the entry is taken into account. I don't find a GTK3 class for GtkIcon though, not sure how to retrieve the icon and take its padding into account as well. Eric, any idea?
(In reply to Simeon Andreev from comment #7) > The GtkComboBox with an entry has two elements, a text field and a GtkIcon. > Via theme .css the nodes on which properties can be set are: > > > combobox > ├── box.linked > │ ├── entry.combo > │ ╰── button.combo > │ ╰── box > │ ╰── arrow > ╰── window.popup > > See: https://developer.gnome.org/gtk3/stable/GtkComboBox.html > > In our theme we specify: > > combobox entry.combo, > combobox button.combo { > padding: 4px; > } > > In Combo.computeNativeSize only the padding of the entry is taken into > account. I don't find a GTK3 class for GtkIcon though, not sure how to > retrieve the icon and take its padding into account as well. Eric, any idea? Does this apply for a read-only Combo? I think that is the hierarchy for a regular Combo, which does not have this bug. The hierarchy for read-only Combos should be this: combobox ╰── box.linked ├── entry.combo ├── button.combo ╰── window.popup
Yes, our problem is with read-only combos.
Created attachment 277913 [details] GTK+ inspector showing css nodes and padding. With the GTK+ inspector I only see padding on some button css node. And the padding is 4px, not 2px. I think the padding is on the entire combo button (the entire area of the combo can be clicked, so its a button). The 4px padding will "move" the entry and the drop-down arrow to the center of the widget, eating up text. Maybe we should retrieve this padding, instead of the cell area padding. Or maybe we need both of those.
(In reply to Simeon Andreev from comment #10) > Maybe we should retrieve this padding, instead of the cell area padding. Or > maybe we need both of those. Perhaps gtk_style_context_get_padding() in Combo.computeNativeSize()? I believe the Button is represented by "buttonHandle".
Created attachment 277917 [details] Comparison with Adwaita and Clearlooks-Phenix GTK3 themes, after adding button style padding to combo width.
New Gerrit change created: https://git.eclipse.org/r/138944
Gerrit change https://git.eclipse.org/r/138944 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=c4407bb1db4994474103fea04c9ab8dac9b730e9
(In reply to Eclipse Genie from comment #14) > Gerrit change https://git.eclipse.org/r/138944 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=c4407bb1db4994474103fea04c9ab8dac9b730e9 Thanks for the patch Simeon, in master now.
Thanks for merging!
Verified with I20190318-1800. Thanks Simeon.
