Community
Participate
Working Groups
Big Sur 11.5.2 Eclipse 4.21 (eclipse-SDK-4.21-macosx-cocoa-aarch64) JDK: Zulu11.48+21-CA for ARM64 Mac Mini M1 (ARM64) The height and border of List items is bigger on aarch64 than x86_64. This also affects the contents of CCombo as it uses a List. Related to Bug #574932
Created attachment 287043 [details] List on x86_64
Created attachment 287044 [details] List on aarch64
Created attachment 287045 [details] CCombo on x86_64
Created attachment 287046 [details] CCombo on aarch64
Problem happens in Table and Tree as well, hence updated the title.
Created attachment 287514 [details] Snippet to show item height change when List font is set This is a snippet to show item height in a List. The item height is more than usual, so text is not vertically centred. But if we simply set the font on the List control the item height is smaller, matching that on Mac x86_64. Uncomment this line to see item height shrink: list.setFont(list.getFont());
Starting with Eclipse 4.22, I have found the SWT AArch64 port to work fantastic. The only problem is this larger row height issue, which was easy for us to workaround like this: https://github.com/diffplug/durian-swt/pull/17/files
@Ned, this also works: control.setFont(control.getFont());
But I think the row height *should* be taller for this macOS SDK. Perhaps the real issue is that the text is not centred vertically in a row/item?
Try doing: System.out.println("Font is " + control.getFont()); control.setFont(control.getFont()); I get "Font is null". > I think the row height *should* be taller for this macOS SDK. macOS 11 has an emphasis on unifying the UI between macOS / iPad, which includes a default UI styling which is big enough to be touch-friendly. But you can still opt-in to the older style, and I think that's the appropriate path for SWT. Using the `setFont(null)` hack, we are getting a pixel-perfect match between x86 and aarch64. We don't want to restyle our application to be iPad-friendly, we want row heights appropriate for mouse & keyboard, not touch.
(In reply to Ned Twigg from comment #11) > Try doing: > > System.out.println("Font is " + control.getFont()); > control.setFont(control.getFont()); > > I get "Font is null". > When I create a TreeViewer with a Tree control, or TableViewer with a Table control, the font is set to non-null.
(In reply to Ned Twigg from comment #11) > Try doing: > > System.out.println("Font is " + control.getFont()); > control.setFont(control.getFont()); > > I get "Font is null". I would consider a null return value as bug. The documentation does not mention it. Hence it must be not-null.
(In reply to Thomas Singer from comment #13) > I would consider a null return value as bug. The documentation does not > mention it. Hence it must be not-null. Nope. The null means, the control has no *specific* font set, and simply uses display default font (org.eclipse.swt.graphics.Device.getSystemFont()).
(In reply to Andrey Loskutov from comment #14) > (In reply to Thomas Singer from comment #13) > > I would consider a null return value as bug. The documentation does not > > mention it. Hence it must be not-null. > > Nope. The null means, the control has no *specific* font set, and simply > uses display default font (org.eclipse.swt.graphics.Device.getSystemFont()). Then this should be the case for all controls on all platforms: if no font explicitly has been set, return null. Otherwise the control itself can interpret the null value and return org.eclipse.swt.graphics.Device.getSystemFont() itself.
(In reply to Ned Twigg from comment #11) > Try doing: > > System.out.println("Font is " + control.getFont()); > control.setFont(control.getFont()); > > I get "Font is null". > > > I think the row height *should* be taller for this macOS SDK. > > macOS 11 has an emphasis on unifying the UI between macOS / iPad, which > includes a default UI styling which is big enough to be touch-friendly. But > you can still opt-in to the older style, and I think that's the appropriate > path for SWT. Using the `setFont(null)` hack, we are getting a pixel-perfect > match between x86 and aarch64. We don't want to restyle our application to > be iPad-friendly, we want row heights appropriate for mouse & keyboard, not > touch. control.getFont() returns the default system font when no font is set explicitly. control.setFont(null) also sets the font to the default system font. So, both control.setFont(control.getFont()) and control.setFont(null) should have the same effect. SWT can set setFont(null) for Table/Tree/List on aarch64 if it fixes the row height bug.
(In reply to Thomas Singer from comment #15) > (In reply to Andrey Loskutov from comment #14) > > (In reply to Thomas Singer from comment #13) > > > I would consider a null return value as bug. The documentation does not > > > mention it. Hence it must be not-null. > > > > Nope. The null means, the control has no *specific* font set, and simply > > uses display default font (org.eclipse.swt.graphics.Device.getSystemFont()). > > Then this should be the case for all controls on all platforms: if no font > explicitly has been set, return null. Otherwise the control itself can > interpret the null value and return > org.eclipse.swt.graphics.Device.getSystemFont() itself. From the code, control.getFont() is not expected to return null. It either returns the non-null font set by setFont() or the default font on all platforms.
