Community
Participate
Working Groups
Created attachment 271850 [details] A screenshot which shows a tab after a mouse-over. To reproduce, its sufficient to run the following code: public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); CTabFolder partStackTabs = new CTabFolder(shell, SWT.RIGHT_TO_LEFT); CTabItem tab1 = new CTabItem(partStackTabs, SWT.NONE); tab1.setText("tab 1"); CTabItem tab2 = new CTabItem(partStackTabs, SWT.NONE); tab2.setText("tab 2"); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } Mouse-over on the tabs results in painted-over tabs as seen on the attached screenshots. Once the mouse pointer has been hovered over the tab, the tab stays "hidden" until another shell is selected. Selecting the tabs works as expected.
It would be nice to get this into 4.7.3.
Not surprisingly, this is caused by org.eclipse.swt.custom.CTabFolder.onMouse(Event), the case for SWT.MouseMove. If I comment out some of the "hot" handling introduced here, for that mouse move event, the problem is gone: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/id?id=8bc31837bf1118e0f6900791d0a755114af85b3e
Seems like a redraw during onMoues MouseMove causes the tabs to vanish.
(In reply to Simeon Andreev from comment #2) > Not surprisingly, this is caused by > org.eclipse.swt.custom.CTabFolder.onMouse(Event), the case for SWT.MouseMove. > > If I comment out some of the "hot" handling introduced here, for that mouse > move event, the problem is gone: > > https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > id?id=8bc31837bf1118e0f6900791d0a755114af85b3e I'm not sure that this is the root cause. This code exists since 3.7 and we don't observe this issue in 3.8.2, we see it only after update to 4.7.2. I also don't see it on 4.8/Windows 10, so this must be GTK3 specific. I guess the problem is caused either by the wrong implementation of the org.eclipse.swt.widgets.Control.redraw(int, int, int, int, boolean) or in the org.eclipse.swt.custom.CTabFolderRenderer.draw(int, int, Rectangle, GC). I hope this is the later. Also it looks like is as if we redraw the (parent) background but fail to redraw the actual tab, probably because we can't find the right tab bounds because we start to search from wrong side (with RTL direction). Just a guess, I haven't looked into related SWT GTK code yet.
Does this issue occur on GTK3 with 4.8?
Yes, we observe it both on 4.7.2 and 4.8.
After some debugging, methods CTabFolderRenderer.drawUnselected and CTabFolderRenderer.drawSelected don't draw the tabs due to draw event clipping not intersecting with the actual event bounds. The event bounds/clipping are set in Control.gtk_draw: @Override long /*int*/ gtk_draw (long /*int*/ widget, long /*int*/ cairo) { ... GdkRectangle rect = new GdkRectangle (); OS.gdk_cairo_get_clip_rectangle (cairo, rect); Event event = new Event (); event.count = 1; Rectangle eventRect = new Rectangle (rect.x, rect.y, rect.width, rect.height); event.setBounds (DPIUtil.autoScaleDown (eventRect)); if ((style & SWT.MIRRORED) != 0) event.x = DPIUtil.autoScaleDown (getClientWidth ()) - event.width - event.x; ... GC gc = event.gc = GC.gtk_new (this, data); Rectangle rect2 = DPIUtil.autoScaleDown(new Rectangle(rect.x, rect.y, rect.width, rect.height)); // Caveat: rect2 is necessary because GC#setClipping(Rectangle) got broken by bug 446075 gc.setClipping (rect2.x, rect2.y, rect2.width, rect2.height); drawWidget (gc); sendEvent (SWT.Paint, event); ... } As seen above, the clipping doesn't take SWT.MIRRORED into account. I assume SWT.RIGHT_TO_LEFT implies SWT.MIRRORED.
Linked patch proposal.
New Gerrit change created: https://git.eclipse.org/r/113224
The regression is from bug 421127, not from bug 479614. Bug 421127 introduced clipping in Control.gtk_draw() with wrong bounds.
See commit 2e2d3d7e7fd5f8bc171072a54847a622718a17d1 added clipping with wrong bounds.
Gerrit change https://git.eclipse.org/r/113224 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cac16b0378941a518f90eb39831fa74b7d393b37
(In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/113224 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=cac16b0378941a518f90eb39831fa74b7d393b37 In master now, thanks for the patch. I'll leave the bug open for 4.7.3.
(In reply to Eric Williams from comment #13) > In master now, thanks for the patch. I'll leave the bug open for 4.7.3. Ping, still interested in backporting this one?
(In reply to Eric Williams from comment #14) > (In reply to Eric Williams from comment #13) > > In master now, thanks for the patch. I'll leave the bug open for 4.7.3. > > Ping, still interested in backporting this one? Yes. I will see if I can provide patches tomorrow. I'm also interested in few other recent GTK 3 patches on master.
(In reply to Eric Williams from comment #14) > (In reply to Eric Williams from comment #13) > > In master now, thanks for the patch. I'll leave the bug open for 4.7.3. > > Ping, still interested in backporting this one? https://git.eclipse.org/r/#/c/115147/
This was actually backported awhile ago.
Andrey/Eric, can you please verify the fix with the latest 4.7.3 M-build?
(In reply to Lakshmi Shanmugam from comment #18) > Andrey/Eric, can you please verify the fix with the latest 4.7.3 M-build? Ping!
(In reply to Dani Megert from comment #19) > (In reply to Lakshmi Shanmugam from comment #18) > > Andrey/Eric, can you please verify the fix with the latest 4.7.3 M-build? > > Ping! I just saw you marked it as VERIFIED. Usually we add a comment where we say with which build it was verified.
(In reply to Dani Megert from comment #20) > (In reply to Dani Megert from comment #19) > > (In reply to Lakshmi Shanmugam from comment #18) > > > Andrey/Eric, can you please verify the fix with the latest 4.7.3 M-build? > > > > Ping! > > I just saw you marked it as VERIFIED. Usually we add a comment where we say > with which build it was verified. Verified in M20180214-1700.
