[GTK] Change the zoom only on scale factor changes of the Shell window

[vogella]

GTK notifies scale-factor on every widget, including a child that is attached to its parent inside the Control constructor. SWT took this for a DPI change, so the half-built child changed the global zoom, received SWT.ZoomChanged and laid out all shells, which sent SWT.Skin to custom widgets like StyledText before their constructor had finished and caused a NullPointerException. Now only the Shell window's notification changes the zoom and sends SWT.ZoomChanged, while image widgets still refresh their images. Regression tests cover both the early Skin event and the Shell path.

Fixes #3458

[github-actions]

Test Results

  224 files  ± 0    224 suites  ±0   26m 52s ⏱️ + 1m 41s
5 033 tests + 2  5 005 ✅ +2   28 💤 ±0  0 ❌ ±0 
7 482 runs  +12  7 261 ✅ +6  221 💤 +6  0 ❌ ±0 

Results for commit 4c1306b. ± Comparison against base commit 18fe3cd.

♻️ This comment has been updated with latest results.

[Copilot]

Copilot review overview

🟢 Approval recommended

The focused fix addresses the reported construction-time event ordering and includes appropriate regression coverage.

Review effort: Balanced
Findings: None

What changed in this PR

Defers GTK DPI-change layouts to prevent SWT.Skin events during widget construction.

Changes:

• Schedules shell relayout asynchronously after scale-factor changes.
• Adds a GTK regression test covering StyledText construction.

File	Description
Display.java	Defers DPI-triggered shell layouts.
Test_org_eclipse_swt_custom_StyledText.java	Verifies skin events occur after construction.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[akurtakov]

Some analysis follow:
Cause: notify::scale-factor is connected on every widget. When a child is attached to its parent, GTK corrects that child's scale, and SWT mistakes this for a DPI change. So the half-built child sets the global zoom and lays out all shells, and that sends the Skin events. With this PR the Skin event is no longer early, but the zoom still flips, and ZoomChanged still goes to the half-built widget.

Suggestion: only the Shell's own window notification should change the global zoom and I don't see a reason why/when non-Shells should send zoom-changed on Gtk. The per-widget hook can stay for refreshing images:

// Widget.dpiChanged: return 0;

// Shell
@OverRide
long dpiChanged (long object, long arg0) {
if (object == shellHandle) {
int scale = GTK.gtk_widget_get_scale_factor (shellHandle);
if (DPIUtil.getDeviceZoom () / 100 != scale) {
display.dpiChanged (scale);
Event event = new Event ();
event.detail = scale;
event.doit = true;
notifyListeners (SWT.ZoomChanged, event);
}
}
return super.dpiChanged (object, arg0);
}

On both GTK3 and GTK4 that should have the effect of no early Skin event and the zoom doesn't change, while real scale changes still work. That should make the async call not needed and make things even more predictable. Please try it.

[vogella]

Thanks, applied.

[Copilot]

🟡 Changes recommended

The Shell event reports a native scale factor instead of the documented zoom percentage.

1 open finding

• Report zoom percentage, not GTK scale factor, in SWT.ZoomChanged · New

🧠 Review effort: Balanced

[Copilot]

🟡 Changes recommended

Shell DPI handling mishandles fixed autoscaling and GTK4 popover-backed child Shells.

1 open finding

• Exclude popover-backed shells from global zoom updates · New

1 resolved since last review

• Report zoom percentage, not GTK scale factor, in SWT.ZoomChanged

🧠 Review effort: Balanced

[akurtakov]

That is a must have to not regress on Gtk 4.

[akurtakov]

The tests are really complicated and non-generic enough. It would be nice to have them in org.eclipse.swt.tests.gtk and use Gtk specific methods directly so it's easier to understand what it does.