Scale Table.INSET by zoom level instead of using fixed pixels

[ShahzaibIbrahim]

The Table.INSET constant defines the spacing in the width of a table cell. Previously, this was a fixed value of 3px, which looks correct at 100% zoom but causes the image and text to appear cramped on higher-DPI displays.

This change defines INSET in points and converts it to pixels based on the current zoom level (e.g. 6px at 200%), ensuring consistent spacing across different monitor scale.

How to Test

• Run the following snippet with 100% primary and 250% secondary monitor zoom
• Note down the width of a cell by moving it from one monitor to other.
• See if the values adhere to zoom levels.

import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class TableInsetTest {

public static void main (String [] args) {
	System.setProperty("swt.autoScale", "quarter");
	System.setProperty("swt.autoScale.updateOnRuntime", "true");
	Display display = new Display ();
	Shell shell = new Shell (display);
	shell.setText("Table Inset Test");
	Table table = new Table (shell, SWT.BORDER | SWT.MULTI);
	table.setLinesVisible(true);
	Rectangle clientArea = shell.getClientArea ();
	table.setBounds (clientArea.x, clientArea.y, 200, 200);
	for (int i=0; i<128; i++) {
		TableItem item = new TableItem (table, SWT.NONE);
		item.setText ("Item " + i);
	}
	table.setSelection (95);
	shell.pack ();
	shell.open ();
	while (!shell.isDisposed ()) {
		if (!display.readAndDispatch ()) display.sleep ();
	}
	display.dispose ();
}
}

Results:
Before Change
Width 150% = 77
Width 250% = 128

After change
Width 150% = 84
Width 250% = 139

[github-actions]

Test Results

   546 files  ±0     546 suites  ±0   32m 59s ⏱️ +43s
 4 431 tests ±0   4 410 ✅  - 4   17 💤 ±0  4 ❌ +4 
16 764 runs  ±0  16 633 ✅  - 4  127 💤 ±0  4 ❌ +4 

For more details on these failures, see this check.

Results for commit feb86f6. ± Comparison against base commit 508ad4a.

♻️ This comment has been updated with latest results.

[fedejeanne]

Makes sense, as did the same changes in Tree before.

One thing I observed during testing (unrelated to this PR!) is that if I move between monitors, the scrollbars are missing on the small monitor.

My setting

• 175% monitor on the left (primary)
• 100% monitor on the right

To reproduce
Start the snippet with these VM arguments:

-Dswt.autoScale=quarter
-Dswt.autoScale.updateOnRuntime=true

Move from 175% monitor to 100% monitor.

Screenshots

175% (OK)

100% (No scrollbar)

Is this known? Can you please create a ticket for it if it isn't?

[fedejeanne]

Failing test unrelated: #2516

[HeikoKlare]

One thing I observed during testing (unrelated to this PR!) is that if I move between monitors, the scrollbars are missing on the small monitor.

It's not the scrollbar that is missing, it's the table not adapting its size upon DPI change while the shell does it. If you enlarge the shell, you will see the scrollbar. Note that this is probably the case for every control, not only for Table.
Usually, size adaptation is done by the applied layout, which is why you only experience that issue when not using any layout for arranging controls. Since no one cared so far, I am not sure if there is really someone caring about a fix for it.

[laeubi]

@HeikoKlare I do not agree that a Layout must be used... as mentioned elsewhere sizing controls directly is absolutely valid for SWT (not that I would recommend it...)!

So one would say, if no Layout is installed, the shell would probably like to scale up/down its childs, otherwise ask the layout to relayout.

[HeikoKlare]

I do not agree that a Layout must be used... as mentioned elsewhere sizing controls directly is absolutely valid for SWT (not that I would recommend it...)!

I do not find the place where I said that you must use a layout. In any case, that's not what I wanted to say. I just explained the reason for the behavior in case of this snippet. And I explained why the issue was probably not identified so far. It's of course fully valid, but given the number of users we know about that currently require non-layouted controls to adapt to DPI changes (which to my knowledge is 0), it's probably not worth to invest effort into that right now.

[fedejeanne]

Since the issue is unrelated, I'm merging this PR.