[macOS 26] Add layer-based border rendering for Text and Combo widgets

[tobiasmelcher]

On macOS 26 (Tahoe) Liquid Glass, all text fields and combo boxes
require a visible border regardless of SWT.BORDER style. This adds
the necessary Cocoa bindings (NSView.setWantsLayer,
CALayer.setBorderColor/
setBorderWidth/setCornerRadius, NSColor.separatorColor/CGColor) and
draws borders via the layer pipeline. The shared logic is extracted
into Control.configureLayerBorder() and the SDK version is cached in
OS.MACH_O_SDK_VERSION.

[tobiasmelcher]

Reproduce the rendering problem of the SWT text control with following simple code snippet:

package org.eclipse.swt.widgets;

import org.eclipse.swt.*;
import org.eclipse.swt.layout.*;

public class TestTextControl {
	public static void main(String[] args) {
		Display display = new Display();
		Shell shell = new Shell(display);
		shell.setText("Text Control Test");
		shell.setLayout(new GridLayout(1, false));

		Text text = new Text(shell, SWT.NONE);
		text.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));
		text.setText("Text 1");

		Text text2 = new Text(shell, SWT.NONE);
		text2.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));
		text2.setText("Text 2");
		shell.setSize(400, 350);
		shell.open();

		while (!shell.isDisposed()) {
			if (!display.readAndDispatch()) {
				display.sleep();
			}
		}
		display.dispose();
	}
}

When running this code with a java vm build against macOS 26 SDK without the changes in this pull request, the UI looks like this:

With the changes of this pull request, it looks like this. The corners are now visible for "Text 2".

I also tested the NSTextField behavior in Objective-C with following code

    NSView *contentView = [self.window contentView];
    
    NSTextField *textField1 = [[NSTextField alloc] initWithFrame:NSMakeRect(20, 200, 360, 24)];
    [textField1 setStringValue:@"setBezeled:NO setBordered:NO"];
    [textField1 setEditable:YES];
    [textField1 setSelectable:YES];
    [textField1 setBezeled:NO];
    [textField1 setBordered:NO];
    [contentView addSubview:textField1];

    NSTextField *textField2 = [[NSTextField alloc] initWithFrame:NSMakeRect(20, 160, 360, 24)];
    [textField2 setStringValue:@"setBezeled:Yes setBordered:NO"];
    [textField2 setEditable:YES];
    [textField2 setSelectable:YES];
    [textField2 setBezeled:YES];
    [textField2 setBordered:NO];
    [contentView addSubview:textField2];
    
    NSTextField *textField3 = [[NSTextField alloc] initWithFrame:NSMakeRect(20, 120, 360, 24)];
    [textField3 setStringValue:@"setBezeled not called setBordered:NO"];
    [textField3 setEditable:YES];
    [textField3 setSelectable:YES];
    [textField3 setBezeled:YES];
    [textField3 setBordered:NO];
    [contentView addSubview:textField3];
    
    NSTextField *textField4 = [[NSTextField alloc] initWithFrame:NSMakeRect(20, 80, 360, 24)];
    [textField4 setStringValue:@"setBezeled and set Bordered not called"];
    [textField4 setEditable:YES];
    [textField4 setSelectable:YES];
    [contentView addSubview:textField4];

one can see that calling setBordered destroys rendering of the corners. setBezeled doesn't have any effect.

[github-actions]

Test Results (macos)

 56 files   -     2   56 suites   - 2   3s ⏱️ - 7m 37s
 26 tests  - 4 545   26 ✅  - 4 298  0 💤  - 247  0 ❌ ±0 
104 runs   - 2 098  104 ✅  - 2 034  0 💤  -  64  0 ❌ ±0 

Results for commit 520d7f3. ± Comparison against base commit f33b79e.

This pull request removes 4545 tests.

org.eclipse.swt.tests.junit.DPIUtilTests ‑ scaleDownFloat
org.eclipse.swt.tests.junit.DPIUtilTests ‑ scaleUpInteger
org.eclipse.swt.tests.junit.JSVGRasterizerTest ‑ testRasterizeWithTargetSize
org.eclipse.swt.tests.junit.JSVGRasterizerTest ‑ testRasterizeWithTargetSizeHavingInvalidHeight
org.eclipse.swt.tests.junit.JSVGRasterizerTest ‑ testRasterizeWithTargetSizeHavingInvalidWidth
org.eclipse.swt.tests.junit.JSVGRasterizerTest ‑ testRasterizeWithTargetSizeWithInvalidSVG
org.eclipse.swt.tests.junit.JSVGRasterizerTest ‑ testRasterizeWithZoom
org.eclipse.swt.tests.junit.JSVGRasterizerTest ‑ testRasterizeWithZoomNegative
org.eclipse.swt.tests.junit.JSVGRasterizerTest ‑ testRasterizeWithZoomWithInvalidSVG
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_SWT ‑ test_errorI
…

♻️ This comment has been updated with latest results.

[tobiasmelcher]

I think I went into the wrong direction. I got following explanation from Gemini. I will try the wantsLayer approach and upload an updated pull request.

---

Description
With the introduction of macOS SDK 26, the rendering behavior of NSTextField has changed significantly, especially concerning legacy bezel styles. Specifically, when isBordered is set to false (or setBordered(false) is called), the control no longer renders a visual boundary. This results in a white-on-white situation where the text input field becomes invisible to the user in the default system theme.

This change is part of Apple's move toward layer-backed controls and the "Liquid Glass" design language, where traditional CPU-based drawing of bezels is being phased out in favor of GPU-accelerated layer properties.

Changes
To ensure the NSTextField remains visible and maintains a native look and feel on newer macOS versions, this PR transitions the border rendering from the legacy NSBezelStyle to a Core Animation layer-based approach:

Enables Layer-Backing: Sets wantsLayer = true for the control.

Manual Border Definition: Uses CALayer properties to define a border that mimics the native appearance.

System Color Integration: Uses NSColor.separatorColor to ensure the border automatically adapts to Light Mode, Dark Mode, and high-contrast accessibility settings.

Refined Geometry: Applies a slight cornerRadius to align with modern macOS UI standards.

Technical Snippet (Implementation Logic)
Instead of relying on the disappearing system bezel, we now define the visual boundary as follows:

Swift
textField.isBordered = false
textField.wantsLayer = true
textField.layer?.borderColor = NSColor.separatorColor.cgColor
textField.layer?.borderWidth = 1.0
textField.layer?.cornerRadius = 4.0
textField.drawsBackground = true
textField.backgroundColor = NSColor.controlBackgroundColor
Impact
Visual Consistency: Restores visibility of text fields in Eclipse-based applications running on macOS 15+.

Forward Compatibility: Moves away from deprecated drawing behaviors toward the recommended AppKit/Core Animation architecture.

No Regression: On older macOS versions, this approach remains functionally identical and provides a cleaner, modern aesthetic.

[HeikoKlare]

Thank you for taking so much time to investigate this, @tobias-melcher. It's great to see the continuously increasing understanding of what changed/happens. Looking forward to hopefully seeing a solution that keeps SWT adopt the latest macOS look & feel. The screenshots already look very promising.

[tobiasmelcher]

Pull request 1e4df2d no longer uses any hack or workaround from my point of view.

Following screenshots are made with -Dorg.eclipse.swt.internal.carbon.smallFonts

1. Light and dark mode from "Console" preferences page without the changes of this pull request running with the homebrew jvm built with MacOS SDK 26. No borders for text and combo box control rendered. White on white - text and combo box control are not detectable.

2. Light and dark mode from "Console" preferences page with the changes of this pull request running with the homebrew jvm. Borders on text and combo box are now visible. The dark mode combo box has still some glitches, it is the best what I could get until now. Any help is highly appreciated.

3. Light and dark mode from "Console" preferences page with the changes of this pull request running with a jvm built against an older MacOS SDK. The changes of this pull request do not have any influence because they are not applied because of call if (OS.VERSION_MAJOR(OS.MACH_O_SDK_VERSION) == 26) {

What do you think? Is it an improvement compared to the current state? Does it make sense to merge these changes?

[Phillipus]

Does it make sense to merge these changes?

I don't think it's a good idea to merge any of these macOS changes so late in 4.40. If there is more time for targeting a later release it allows (at least me) more time to test on macOS 15, 26 and on various combinations. It would be a shame to find serious regressions in 4.40.

[tobiasmelcher]

Does it make sense to merge these changes?

I don't think it's a good idea to merge any of these macOS changes so late in 4.40. If there is more time for targeting a later release it allows (at least me) more time to test on macOS 15, 26 and on various combinations. It would be a shame to find serious regressions in 4.40.

No worries, I don't want to break any release. It is fine for me. Just wanted to know if the change goes into the right direction.

[Phillipus]

No worries, I don't want to break any release. It is fine for me. Just wanted to know if the change goes into the right direction.

Thanks. I want to spend some focussed time testing this and the other changes to Mac for macOS 26 support and also test for possible regressions on earlier macOS versions (I have various Mac setups including Intel). It would be helpful if the changes which are proposed could have longer testing period into 4.41.

Thanks for your work on this!

[HeikoKlare]

Thanks again for working on this.

The proposed changes look like an improvement, as the text fields are clearly separated from their surrounding again. Still, they look rather customized to me, as the text fields are quite compact with the lack of padding between the border/bezel and the text. Also the background color becomes different with the change. Is that intended?

Was there some essential impediment with the original approach of this PR? I am just asking because the original screenshots looked very "native" and thus quite promosing.

[tobiasmelcher]

Sorry for the delay @HeikoKlare . I now started again to look into this topic.

I introduced the LiquidGlassStrategy enum in [520d7f3] to be able to compare the two rendering approaches side-by-side:

• LAYER_BORDER — draws the border manually via a CALayer on top of the (now invisible) native bezel.
• SKIP_DISPLAY_OVERRIDES — keeps the native bezel by no longer overriding drawRect:, setNeedsDisplay: and setNeedsDisplayInRect: on SWTTextField / SWTComboBox during class registration.

You are right: the LAYER_BORDER approach does not look great. The padding is off, the background color differs, and the result feels customized rather than native. The SKIP_DISPLAY_OVERRIDES approach clearly produces a more native look (see screenshots below).

My hesitation with SKIP_DISPLAY_OVERRIDES is that I cannot fully assess the side effects of no longer overriding those native display methods. addEventMethods(...) has been the established mechanism across all NSView-based widgets for many years, and skipping the display-invalidation overrides specifically for NSTextField / NSComboBox could surface subtle regressions in redraw / partial invalidation / region handling scenarios that may only become visible later. That uncertainty was the original motivation for trying the layer-based approach.

Comparison screenshots (all made with the homebrew jvm built with MacOS SDK 26). Please only compare the text field and the combo box which are modified.

	Light mode	Dark mode
LAYER_BORDER (without -Dorg.eclipse.swt.internal.carbon.smallFonts)
LAYER_BORDER (with -Dorg.eclipse.swt.internal.carbon.smallFonts)
SKIP_DISPLAY_OVERRIDES (without -Dorg.eclipse.swt.internal.carbon.smallFonts)
SKIP_DISPLAY_OVERRIDES (with -Dorg.eclipse.swt.internal.carbon.smallFonts)

What do you think?