Adjust selection bounds for CTabRenderring #3533

ShahzaibIbrahim · 2025-11-11T12:27:57Z

Selected tabs highlight look slightly off and more noticeable when zoom is not 100%. These adjusted value shows no gaps from top and better aligned highlights for tabs (Theme is enabled)

Results:

At 300% Before Changes:

From top left one px perhaps is missing and from top it is slightly downwards leaving the gap on top.

At 300% After Changes:

github-actions · 2025-11-11T13:29:42Z

Test Results

0 files - 3 018 0 suites - 3 018 0s ⏱️ - 2h 15m 30s
0 tests - 8 236 0 ✅ - 7 987 0 💤 - 248 0 ❌ - 1
0 runs - 23 628 0 ✅ - 22 836 0 💤 - 791 0 ❌ - 1

Results for commit fe5e96b. ± Comparison against base commit 7829422.

♻️ This comment has been updated with latest results.

HeikoKlare

With this change, the highlight line looks very thin (on 100%):

This is how it used to look:

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java

ShahzaibIbrahim · 2025-11-13T13:34:43Z

@HeikoKlare I found the problem. Here were drawing the tab from (0,0) pixel but still using initial item location (1,1) and hence the gap was visible. I also updated the height to 3 when we draw from (0,0) so we have enough height for the selection marker.

The code that caused the gap:
https://github.com/vi-eclipse/eclipse.platform.ui/blob/8be04038fd7a1dd5cf4f7972e7813d0925181315/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java#L572C2-L577

HeikoKlare

The appearance is in my opinion much better than before. I have some questions/remarks on the current propose.
And the appearance with round tabs now became worse (than it already was before):

We may probably do something similar than in SWT to draw a proper shape. The current adjustments by 1 point based on cornerSize do not look sufficient.

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java

ShahzaibIbrahim · 2025-11-17T14:02:50Z

The appearance is in my opinion much better than before. I have some questions/remarks on the current propose. And the appearance with round tabs now became worse (than it already was before):

We may probably do something similar than in SWT to draw a proper shape. The current adjustments by 1 point based on cornerSize do not look sufficient.

While I agree the rounded tabs should be adapted. But I wouldn't say it looks "worse" than master. Here's the SS comparing this PR and master state.

I would suggest that we fix the shape in another PR. This PR fixes the gap that we had from the top.

amartya4256 · 2025-11-24T14:13:27Z

I pulled the branch and ran it on 250%. This is how it looks for me:

I can see a small gap in the left and at the top. Is it supposed to look like this?

HeikoKlare · 2025-11-25T08:43:15Z

I can see a small gap in the left and at the top. Is it supposed to look like this?

No, it should be fully aligned at the top, left and right without any gaps at every zoom.

ShahzaibIbrahim · 2025-12-03T12:15:03Z

I pulled the branch and ran it on 250%. This is how it looks for me:

I can see a small gap in the left and at the top. Is it supposed to look like this?

Are you sure you checked out master-517 from platform.ui? We also have master-517 for SWT. I checked again and there is no gap for the highlight.

HeikoKlare · 2025-12-03T17:11:12Z

@amartya4256 can you please retest this? Unfortunately, I have currently monitor available that I can set to 250%. Everything up to 225% looks fine to me.

HeikoKlare · 2025-12-03T17:14:26Z

I would suggest that we fix the shape in another PR. This PR fixes the gap that we had from the top.

@ShahzaibIbrahim But maybe that would require another readaptation of the calculations. Shouldn't we just fix it right away? Then it would also make more sense to take into account the outlineBoundsForOutline as those are used by the calculations for the (potentially rounded) borders.

ShahzaibIbrahim · 2025-12-04T14:35:12Z

I would suggest that we fix the shape in another PR. This PR fixes the gap that we had from the top.

@ShahzaibIbrahim But maybe that would require another readaptation of the calculations. Shouldn't we just fix it right away? Then it would also make more sense to take into account the outlineBoundsForOutline as those are used by the calculations for the (potentially rounded) borders.

I have added a commit to put highlight on rounded tabs. Although it looks big jagged as original one (non-selected rounded tabs) also bit jagged. I have reused the shape.

Here's the comparison of the selected and unselected tabs:

eclipse-platform-bot · 2025-12-04T14:39:18Z

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF

Warning

🚧 This PR cannot be modified by maintainers because edits are disabled or it is created from an organization repository. To obtain the required changes apply the git patch manually as an additional commit.

Git patch

From f5ccee2902ee5e62162ce449cdfc45991ef6f3f6 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Thu, 4 Dec 2025 14:45:45 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
index 249542c521..ca4f9ad426 100644
--- a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: org.eclipse.e4.ui.workbench.renderers.swt;singleton:=true
-Bundle-Version: 0.16.1000.qualifier
+Bundle-Version: 0.16.1100.qualifier
 Bundle-Name: %pluginName
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.52.0

Further information are available in Common Build Issues - Missing version increments.

Selected tabs highlight look slightly off and more noticeable when zoom is not 100%. These adjusted value shows no gaps from top and better aligned highlights for tabs (Theme is enabled)

HeikoKlare · 2025-12-05T09:05:42Z

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java

+				int horizontalOffset = itemIndex == 0 || cornerSize == SQUARE_CORNER ? 0 : 1;
+				int widthAdjustment = cornerSize == SQUARE_CORNER ? 0 : 1;


Since cornerSize == SQUARE_CORNER in this branch, these variable can be completely removed, can't they?

HeikoKlare · 2025-12-05T09:09:39Z

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java

+			} else {
+				int[] highlightShape = Arrays.copyOf(tabOutlinePoints, tabOutlinePoints.length);
+				// Update Y coordinates in shape to apply highlight thickness
+				int thickness = 2;


Why don't we need to apply the more complex calculation logic used for the SQUARE_CORNER case here? This seems to lead to hightlights that are far too thick:

Also note that there are blue-colored fragments remaining to the left and right. Seems like some more tweaking of the shape points is necessary.

Screenshots are taken at 175%.

HeikoKlare · 2025-12-05T09:10:59Z

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java

+				int[] highlightShape = Arrays.copyOf(tabOutlinePoints, tabOutlinePoints.length);
+				// Update Y coordinates in shape to apply highlight thickness
+				int thickness = 2;
+				int highlightY = onBottom ? bottomY - thickness : thickness + 1;


This introduces a regression, as it uses onBottom instead of the highlightOnTop. I think there is even a mistake in the general distinction just based on cornerSize == SQUARE_CORNER. You will also need to draw a rectangle in case of round corners but when the highlight is not at the end with the rounding, i.e., if highlightOnTop != onBottom. So the condition for drawing a rectangle probably needs to be cornerSize == SQUARE_CORNER || highlightOnTop == onBottom.

ShahzaibIbrahim linked an issue Nov 11, 2025 that may be closed by this pull request

CTabFolder highlight not positioned/sized correctly on zoom != 100% vi-eclipse/Eclipse-Platform#517

Open

HeikoKlare reviewed Nov 11, 2025

View reviewed changes

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java Outdated Show resolved Hide resolved

ShahzaibIbrahim force-pushed the master-517 branch 2 times, most recently from b510ca2 to 8be0403 Compare November 13, 2025 13:30

ShahzaibIbrahim force-pushed the master-517 branch from 8be0403 to c878f05 Compare November 13, 2025 13:34

HeikoKlare reviewed Nov 13, 2025

View reviewed changes

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java Outdated Show resolved Hide resolved

....ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java Outdated Show resolved Hide resolved

ShahzaibIbrahim force-pushed the master-517 branch 2 times, most recently from 88fc99e to a4713f9 Compare November 17, 2025 11:48

ShahzaibIbrahim marked this pull request as draft November 17, 2025 12:00

ShahzaibIbrahim marked this pull request as ready for review November 17, 2025 14:07

ShahzaibIbrahim added 2 commits December 4, 2025 15:39

Adjust selection bounds for CTabRenderring

6e3c996

Selected tabs highlight look slightly off and more noticeable when zoom is not 100%. These adjusted value shows no gaps from top and better aligned highlights for tabs (Theme is enabled)

Adjust selection bounds for Rounded Tabs

fe5e96b

ShahzaibIbrahim force-pushed the master-517 branch from 691b22d to fe5e96b Compare December 4, 2025 14:39

HeikoKlare requested changes Dec 5, 2025

View reviewed changes

		int horizontalOffset = itemIndex == 0 \|\| cornerSize == SQUARE_CORNER ? 0 : 1;
		int widthAdjustment = cornerSize == SQUARE_CORNER ? 0 : 1;

Adjust selection bounds for CTabRenderring #3533

Are you sure you want to change the base?

Adjust selection bounds for CTabRenderring #3533

Conversation

ShahzaibIbrahim commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Results:

Uh oh!

github-actions bot commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

HeikoKlare left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ShahzaibIbrahim commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HeikoKlare left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ShahzaibIbrahim commented Nov 17, 2025

Uh oh!

amartya4256 commented Nov 24, 2025

Uh oh!

HeikoKlare commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ShahzaibIbrahim commented Dec 3, 2025

Uh oh!

HeikoKlare commented Dec 3, 2025

Uh oh!

HeikoKlare commented Dec 3, 2025

Uh oh!

ShahzaibIbrahim commented Dec 4, 2025

Uh oh!

eclipse-platform-bot commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HeikoKlare Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

HeikoKlare Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

HeikoKlare Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ShahzaibIbrahim commented Nov 11, 2025 •

edited

Loading

github-actions bot commented Nov 11, 2025 •

edited

Loading

ShahzaibIbrahim commented Nov 13, 2025 •

edited

Loading

HeikoKlare commented Nov 25, 2025 •

edited

Loading

eclipse-platform-bot commented Dec 4, 2025 •

edited

Loading