Community
Participate
Working Groups
Created attachment 263905 [details] Combo garbled on re-size if SWT.READ_ONLY is specified Creating a Combo with SWT.READ_ONLY causes garbling on re-sizes: specifically when changing the width. See the attached screenshot.
Created attachment 263906 [details] Snippet reproducing the issue
My initial thoughts on this bug: it seems on GTK3.18, the Combo actually shrinks in size, i.e. the arrow on the right actually moves in the direction of the "Select..." label. On GTK3.20 the Combo doesn't change size, but is simply moved over, until it goes off the screen. On 3.20 the Combo never gets "compacted" like it does on 3.18. More investigation to follow.
Update: it seems the issue of the overdrawing is being caused by the Combo's clip being significantly larger than the allocation. Adjusting the clip using gtk_widget_set_clip() fixes the issue, but I need to find a proper place to put that call. Also on GTK3.18 the Combo resizes from the right corner to the left, i.e. the arrow moves and the right side shrinks towards the beginning of the string. On 3.20 the opposite happens (with the set_clip fix), the Combo shrinks from the left side and the end of the sentence is still present.
(In reply to Eric Williams from comment #3) > Update: it seems the issue of the overdrawing is being caused by the Combo's > clip being significantly larger than the allocation. Adjusting the clip > using gtk_widget_set_clip() fixes the issue, but I need to find a proper > place to put that call. > > Also on GTK3.18 the Combo resizes from the right corner to the left, i.e. > the arrow moves and the right side shrinks towards the beginning of the > string. On 3.20 the opposite happens (with the set_clip fix), the Combo > shrinks from the left side and the end of the sentence is still present. You probably need to override gtk_size_allocate in Combo for that. Feel free to share whatever info you have gathered and I'll continue it.
(In reply to Alexander Kurtakov from comment #4) > You probably need to override gtk_size_allocate in Combo for that. Feel free > to share whatever info you have gathered and I'll continue it. I don't really have much more info apart from what's in comment 3. A good way to see this bug is to play around in GTK inspector. IIRC once the Combo is garbled, using GTK inspector you can see that the clip size is way larger than the Combo size.
*** Bug 515026 has been marked as a duplicate of this bug. ***
(In reply to Eric Williams from comment #6) > *** Bug 515026 has been marked as a duplicate of this bug. *** From bug 515026 comment 10: the commit that causes this bug is https://github.com/GNOME/gtk/commit/3e0694284785153944255a0501e84a76c491e4b4.
Some more info: This bug is a result of GTK3.20 minimum size changes. As of GTK3.20, many widgets do not shrink past their minimum size. In this case, the Combo stays the size of the largest text in its menu. This is already a departure from GTK3.18 behavior, since in 3.18 it was possible to shrink the Combo past its minimum size. In addition to this, the commit mentioned in comment 7 causes the Combo to be overdrawn. There is a half solution to fix this, which involves manually setting the widget's clip in Combo.setBounds(). However, this does not solve the issue entirely as Alt-tabbing back and forth restores the clip to the wrong size and overdrawing happens again. Still investigating a better fix.
New Gerrit change created: https://git.eclipse.org/r/96035
*** Bug 514189 has been marked as a duplicate of this bug. ***
So there are actually two bugs here. 1) The overdrawing: this is where the Combo overdraws onto the Label next to it and makes quite a mess. It's caused by the commit referenced in comment 7, and can be fixed. 2) The Combo resize issue: this bug is what causes the left edge of the Combo to be moved "under" the Label. Instead of the right edge of the Combo shrinking in width towards the Label, the x position of the Combo's box becomes negative and thus wraps underneath the Label. The commit that introduces this is: https://github.com/GNOME/gtk/commit/222c43fc60362eeb97ce2d5e3a5583a69a2e30ef I discovered this by reverting the commit from problem 1) in GTK, and noticed that problem 2) was still occurring. I'll continue to look into problem 2), and I'll push a patch for problem 1) in the meantime.
Gerrit change https://git.eclipse.org/r/96035 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=7b0cb58a2aedcac5c0973ddf0a9b4ab467c9e875
(In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/96035 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=7b0cb58a2aedcac5c0973ddf0a9b4ab467c9e875 Patch in master now.
Verified in I20180507-2205.
*** Bug 488489 has been marked as a duplicate of this bug. ***
*** Bug 532883 has been marked as a duplicate of this bug. ***
