Community
Participate
Working Groups
Created attachment 286811 [details] table on cocoa (x86_64 at left, aarch64 at right) If you create a Shell and populate it like so: shell.setLayout(new FillLayout()); Table table = new Table(shell, SWT.NONE); for (int i = 0; i < 10; ++i) { TableItem item = new TableItem(table, SWT.NONE); item.setText(Integer.toString(i + 1)); } then you get a very different result under AArch64 than on x86_64. The item height is much taller, there is a fat white border around the table contents, and the table selection has rounded corners rather than a flat rectangle all the way to the edge.
Yes, I can confirm this. Not sure if this is a bug or a feature.
This is because eclipse launcher SDK version On x86_64 SDK used is 10.14 On aarch64 SDK used is 11 But the way forward is to use latest SDK and update SWT to MacOS 11 SDK.
Thanks for the info, Sravan, that makes sense.
If you set table.setFont(null) then you get the narrower height. Not sure if that is desired behavior given that the javadoc for Control.setFont(Font) says: "Sets the font that the receiver will use to paint textual information to the font specified by the argument, or to the default font for that kind of control if the argument is null."
Interesting! Out of the box, the switch from `10.14` to `11.0` is pretty significant in terms of design. Both tables and trees are much much taller, unless you do `setFont(null)` in which case things look fairly similar to how they do in `10.14`. However, one big change even after calling `setFont(null)` is that all tables and trees have a pretty wide inset border. In my app, all of these look quite bad, especially the ones with owner draw. This style is very different from the tables and trees on either Windows or GTK. Luckily, it is possible to set `NSTableView.Style.fullWidth`, which gives the old behavior. I think that would be the right default for SWT to use, since it matches the previous behavior and also the behavior of other systems. I think the surprising `setFont(null)` behavior is partially explained by "The automatic style means the system uses the table view’s position in the view hierarchy to help determine its appearance.", which comes from these docs: https://developer.apple.com/design/human-interface-guidelines/macos/overview/whats-new-in-macos/ The mac progression is 10.14 (Mojave), 10.15 (Catalina), 11 (BigSur). BigSur marketshare within mac is currently very low. https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/ If we bump SDK to 11, will BigSur become the new mimimum required version? Is Mojave the current minimum required version?
I guess because Apple Silicon requires a minimum of Big Sur, that has to be the baseline going forward to get parity between x86_64 and aarch64.
That's my guess too. If so, we might want to possibly consider treating MacOS 11 as a new windowing system. e.g. - cocoa.macosx.x86_64 - cocoa11.macosx.x86_64 - cocoa11.macosx.aarch64 It's also possible to ship an old version of SWT if you need support for legacy OS and ship the new version of SWT for BigSur and forward. But in that case (C), user code will need to detect which SWT jar is being used to adjust owner-draw elements between 10.x and 11. The SDK11 cocoa is a breaking change compared to SDK10. I don't mean to sidetrack the issue off of tables, but the battery life and performance of the M1 macs is really incredible, I'm really glad that the Eclipse Foundation was so early to releasing these SWT artifacts so we can work out these issues so we can have high-quality support for Apple Silicon. Thanks Sravan, Lakshmi, and anyone else who made it happen!
Currently eclipse supports Yosemite(10.10) and above. To support this we use SDK version 10.14. The minimum version is controlled by MACOSX_MIN_VERSION flag during build. For aarch 64 the minimum supported version is Macos 11, need to use Xcode 12.4 with Macos SDK 11. To get parity we should use same SDK in both architectures and fix any problems we encounter. Since we(me or Lakshmi) don't have a machine, we need community help on testing with M1 processor.
(In reply to Sravan Kumar Lakkimsetti from comment #8) > Currently eclipse supports Yosemite(10.10) and above. To support this we use > SDK version 10.14. > > The minimum version is controlled by MACOSX_MIN_VERSION flag during build. > > For aarch 64 the minimum supported version is Macos 11, need to use Xcode > 12.4 with Macos SDK 11. > > To get parity we should use same SDK in both architectures and fix any > problems we encounter. > > Since we(me or Lakshmi) don't have a machine, we need community help on > testing with M1 processor. Happy to test and report on my Mac Mini M1. Is there any way you or Lakshmi can get an M1 machine? I'd donate to a fund.
(In reply to Phil Beauvoir from comment #9) > > Happy to test and report on my Mac Mini M1. > > Is there any way you or Lakshmi can get an M1 machine? I'd donate to a fund. Thank you for the offer, but it would be better if you can contribute to foundation to provide us a machine that can be used for automated tests like https://ci.eclipse.org/releng/computer/ta9y0-macos-10.15/
(In reply to Sravan Kumar Lakkimsetti from comment #10) > (In reply to Phil Beauvoir from comment #9) > > > > Happy to test and report on my Mac Mini M1. > > > > Is there any way you or Lakshmi can get an M1 machine? I'd donate to a fund. > > Thank you for the offer, but it would be better if you can contribute to > foundation to provide us a machine that can be used for automated tests like > https://ci.eclipse.org/releng/computer/ta9y0-macos-10.15/ (Sorry to hijack this thread, just one more question) Is there a specific fund for that achine? Or just a general donation to the Eclipse Foundation?
(In reply to Phil Beauvoir from comment #11) > (In reply to Sravan Kumar Lakkimsetti from comment #10) > > (In reply to Phil Beauvoir from comment #9) > > > > > > Happy to test and report on my Mac Mini M1. > > > > > > Is there any way you or Lakshmi can get an M1 machine? I'd donate to a fund. > > > > Thank you for the offer, but it would be better if you can contribute to > > foundation to provide us a machine that can be used for automated tests like > > https://ci.eclipse.org/releng/computer/ta9y0-macos-10.15/ > > (Sorry to hijack this thread, just one more question) Is there a specific > fund for that achine? Or just a general donation to the Eclipse Foundation? At foundation we try to attach to a cloud instance. Let me check with foundation regarding this one.
As per, https://developer.apple.com/documentation/appkit/nstableview/3622475-style?language=objc The default style on macOS 11 is NSTableViewStyleAutomatic and Apps that link to previous macOS versions default to NSTableViewStylePlain. So, setting the style to NSTableViewStylePlain in the code could fix the problem.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187183
(In reply to Eclipse Genie from comment #14) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187183 Phil, Ned, could you please give the patch a try on Mac M1 and see if it fixes the problem?
(In reply to Lakshmi P Shanmugam from comment #15) > (In reply to Eclipse Genie from comment #14) > > New Gerrit change created: > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187183 > > Phil, Ned, could you please give the patch a try on Mac M1 and see if it > fixes the problem? Hi Lakshmi, good to see you back! :-) Thanks for looking at this. Will this Gerrit be committed into an I-build? I can test that.
(In reply to Phil Beauvoir from comment #16) > (In reply to Lakshmi P Shanmugam from comment #15) > > (In reply to Eclipse Genie from comment #14) > > > New Gerrit change created: > > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187183 > > > > Phil, Ned, could you please give the patch a try on Mac M1 and see if it > > fixes the problem? > > Hi Lakshmi, good to see you back! :-) Thanks Phil! :) > > Thanks for looking at this. > > Will this Gerrit be committed into an I-build? I can test that. I was hoping to have the fix tested on M1 before committing it. Let me try that, if not will push the change next week to test with the I-build.
(In reply to Lakshmi P Shanmugam from comment #17) > I was hoping to have the fix tested on M1 before committing it. Let me try > that, if not will push the change next week to test with the I-build. I have never been able to figure out how to get the code from a Gerrit and use it locally in a test Eclipse environment. Are there instructions?
(In reply to Phil Beauvoir from comment #18) > (In reply to Lakshmi P Shanmugam from comment #17) > > > I was hoping to have the fix tested on M1 before committing it. Let me try > > that, if not will push the change next week to test with the I-build. > > I have never been able to figure out how to get the code from a Gerrit and > use it locally in a test Eclipse environment. Are there instructions? Please see these links: Get SWT sources from Git -> https://www.eclipse.org/swt/git.php Fetching from gerrit -> https://wiki.eclipse.org/EGit/User_Guide#Working_with_Gerrit Once you have the code & fix in the workspace, run a new Eclipse configuration to launch child eclipse. Or run the ControlExample from the examples project. No native build is required for the patch. Pls let me know if you have any questions. Thanks!
I've cloned https://www.eclipse.org/swt/git.php but I don' see the changes for this commit anywhere.
(In reply to Phil Beauvoir from comment #20) > I've cloned https://www.eclipse.org/swt/git.php but I don' see the changes > for this commit anywhere. I mean https://git.eclipse.org/r/platform/eclipse.platform.swt.git
I'm going to have to admit defeat on getting SWT to run in Eclipse. After 4 hours of trial and error I managed to at least import the SWT project, rename the .classpath file but now get when trying to run child Eclipse: java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: no swt-cocoa-4948r9 in java.library.path: [/Users/phillipus/Library/Java/Extensions, /Library/Java/Extensions, /Network/Library/Java/Extensions, /System/Library/Java/Extensions, /usr/lib/java, .] no swt-cocoa in java.library.path: [/Users/phillipus/Library/Java/Extensions, /Library/Java/Extensions, /Network/Library/Java/Extensions, /System/Library/Java/Extensions, /usr/lib/java, .] no swt in java.library.path: [/Users/phillipus/Library/Java/Extensions, /Library/Java/Extensions, /Network/Library/Java/Extensions, /System/Library/Java/Extensions, /usr/lib/java, .] Can't load library: /Users/phillipus/.swt/lib/macosx/x86_64/libswt-cocoa-4948r9.jnilib Can't load library: /Users/phillipus/.swt/lib/macosx/x86_64/libswt-cocoa.jnilib Can't load library: /Users/phillipus/.swt/lib/macosx/x86_64/libswt.jnilib And I still can't see the reddit commit for this bug. Thomas - are you able to test this?
I managed to get it to work. Missing parts of the puzzle for me: 1. Get SWT code from https://user@git.eclipse.org/r/a/platform/eclipse.platform.swt 2. Get SWT Binary code from https://user@git.eclipse.org/r/a/platform/eclipse.platform.swt.binaries 3. In Egit SWT project right click repository and do "Fetch from Gerrit" and get the required change branch (in SmartGit do "Fetch More") 4. In Egit SWT Binary project need to check out correct binary version branch Lakshmi, your patch fixes the extra padding in a Tree, but makes no difference to a Table. And: Bug #575114 - fixes this Bug #574855 - fixes this Bug #575696 - does not fix, same problem
Created attachment 287409 [details] Clipped text But there's a problem with some text clipping in a Tree. Look at the "Startup and Shutdown" node in Preferences.
Lakshmi, I am deeply impressed by how well your patches work, especially since you are not able to test them. An M
Sorry, prev comment was early send (tab enter, no way to delete) Lakshmi, I am deeply impressed by how well your patches work, especially since you don't have resources to test with. I think it would be a lot easier if you had a machine to test on. An M1 Mac Mini is only $700, and we are spending so many developer hours on long roundtrips. I am going to email you to ask for an address. I am happy to just ship a new M1 Mac Mini to your workplace for you to keep. (Email to follow).
Another thing fixed by using NSTableViewStylePlain is the unnecessary horizontal scroll bar in a table is no longer shown.
(In reply to Phil Beauvoir from comment #23) > Lakshmi, your patch fixes the extra padding in a Tree, but makes no > difference to a Table. > > And: > > Bug #575114 - fixes this > Bug #574855 - fixes this > Bug #575696 - does not fix, same problem I should correct this statement. - The patch eliminates the white border in all cases but the item height is still taller. - A List's text is not centrally aligned vertically as shown in Bug #57696 - As noted in Bug #575260 if a Table or Tree is created with style SWT.BORDER it has the same effect as NSTableViewStylePlain.
(In reply to Phil Beauvoir from comment #28) > - A List's text is not centrally aligned vertically as shown in Bug #57696 Should be Bug #575696
(In reply to Phil Beauvoir from comment #28) > - As noted in Bug #575260 if a Table or Tree is created with style > SWT.BORDER it has the same effect as NSTableViewStylePlain. But with one difference: > Another thing fixed by using NSTableViewStylePlain is the unnecessary > horizontal scroll bar in a table is no longer shown. Using SWT.BORDER in current version of SWT we still get the unnecessary horizontal scroll bar. So NSTableViewStylePlain is the real fix here.
(In reply to Ned Twigg from comment #26) > Sorry, prev comment was early send (tab enter, no way to delete) > > Lakshmi, I am deeply impressed by how well your patches work, especially > since you don't have resources to test with. I think it would be a lot > easier if you had a machine to test on. An M1 Mac Mini is only $700, and we > are spending so many developer hours on long roundtrips. I am going to email > you to ask for an address. I am happy to just ship a new M1 Mac Mini to your > workplace for you to keep. (Email to follow). Thanks a lot Ned, that's very kind. I've just replied to your email. Just adding here again for completeness, we are checking with the EF on how to accept the contribution and have the machine accessible to us.
(In reply to Phil Beauvoir from comment #28) > (In reply to Phil Beauvoir from comment #23) > > Lakshmi, your patch fixes the extra padding in a Tree, but makes no > > difference to a Table. > > > > And: > > > > Bug #575114 - fixes this > > Bug #574855 - fixes this > > Bug #575696 - does not fix, same problem > > I should correct this statement. > > - The patch eliminates the white border in all cases but the item height is > still taller. > > - A List's text is not centrally aligned vertically as shown in Bug #57696 > > - As noted in Bug #575260 if a Table or Tree is created with style > SWT.BORDER it has the same effect as NSTableViewStylePlain. Thanks Phil for taking time to setup and test the patch. We have M3 next week, that's why I requested your help to get this tested and committed early. From your comments, the patch fixes a couple of issues (Bug #575114 and Bug #574855), but not this bug. So, I'll go ahead and commit the change. Let's then close the fixed issues and work on those that are still open.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187183 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=58d985756494db80bd140ab9527e2721e507ca1c
I'm not being kind, support for the latest MacOS is essential for applications which depend on SWT, including the Eclipse IDE. The Eclipse Foundation has a budget of $6-7 million, engineers cost $100k+, and an M1 costs $700. I'm disillusioned with the Eclipse Foundation's stewardship of SWT, the engineers working on SWT are doing a great job but my experience has been that giving resources to the Eclipse Foundation has not made their way to SWT developers in a timely fashion. I provisioned a cloud machine and sent you the login information. I'm very interested to support SWT developers directly without the overhead and delays of the Foundation.
(In reply to Ned Twigg from comment #34) > I'm not being kind, support for the latest MacOS is essential for > applications which depend on SWT, including the Eclipse IDE. The Eclipse > Foundation has a budget of $6-7 million, engineers cost $100k+, and an M1 > costs $700. I'm disillusioned with the Eclipse Foundation's stewardship of > SWT, the engineers working on SWT are doing a great job but my experience > has been that giving resources to the Eclipse Foundation has not made their > way to SWT developers in a timely fashion. > > I provisioned a cloud machine and sent you the login information. I'm very > interested to support SWT developers directly without the overhead and > delays of the Foundation. Word. SWT lies at the core of the Eclipse UI, and as every part of Eclipse UI depends on it I'm surprised that more resources are not allocated to it.
In our RCP app, table and tree item heights are taller on Apple Silicon compared with Intel macOS. This little trick makes them the "normal" height. tree.setFont(tree.getFont()); table.setFont(table.getFont());
(In reply to Phil Beauvoir from comment #24) > Created attachment 287409 [details] > Clipped text > > But there's a problem with some text clipping in a Tree. Look at the > "Startup and Shutdown" node in Preferences. I opened Bug #577055 for this issue.
Latest I-build with the fix - https://download.eclipse.org/eclipse/downloads/drops4/I20211104-1800/
(In reply to Lakshmi P Shanmugam from comment #38) > Latest I-build with the fix - > https://download.eclipse.org/eclipse/downloads/drops4/I20211104-1800/ Thanks Lakshmi. To summarise my own use case: - Your patch eliminates the extra padding in Table, Tree and List - Item height is still taller but this can be worked around by using the setFont(getFont()) trick described above (I just hope you and Sravan get a Mac M1 to test on. One day Apple will no longer ship Intel Macs and Rosetta 2) Phil
(In reply to Phil Beauvoir from comment #39) > (In reply to Lakshmi P Shanmugam from comment #38) > > Latest I-build with the fix - > > https://download.eclipse.org/eclipse/downloads/drops4/I20211104-1800/ > > Thanks Lakshmi. > > To summarise my own use case: > > - Your patch eliminates the extra padding in Table, Tree and List > - Item height is still taller but this can be worked around by using the > setFont(getFont()) trick described above Increased Item height is the new native behaviour on BigSur. On BigSur the Table rowHeight is 24pt, while on 10.15 it was 17pt: https://wiki.lazarus.freepascal.org/macOS_Big_Sur_changes_for_developers#Table_Views I’m not sure if we should change the default row height.
(In reply to Niraj Modi from comment #40) > (In reply to Phil Beauvoir from comment #39) > > (In reply to Lakshmi P Shanmugam from comment #38) > > > Latest I-build with the fix - > > > https://download.eclipse.org/eclipse/downloads/drops4/I20211104-1800/ > > > > Thanks Lakshmi. > > > > To summarise my own use case: > > > > - Your patch eliminates the extra padding in Table, Tree and List > > - Item height is still taller but this can be worked around by using the > > setFont(getFont()) trick described above > > Increased Item height is the new native behaviour on BigSur. > On BigSur the Table rowHeight is 24pt, while on 10.15 it was 17pt: > https://wiki.lazarus.freepascal.org/ > macOS_Big_Sur_changes_for_developers#Table_Views > > I’m not sure if we should change the default row height. With the increased row height text is not vertically centred in Lists and also in Tree/Table editors.
(In reply to Phil Beauvoir from comment #41) > (In reply to Niraj Modi from comment #40) > > (In reply to Phil Beauvoir from comment #39) > > > (In reply to Lakshmi P Shanmugam from comment #38) > > > > Latest I-build with the fix - > > > > https://download.eclipse.org/eclipse/downloads/drops4/I20211104-1800/ > > > > > > Thanks Lakshmi. > > > > > > To summarise my own use case: > > > > > > - Your patch eliminates the extra padding in Table, Tree and List > > > - Item height is still taller but this can be worked around by using the > > > setFont(getFont()) trick described above > > > > Increased Item height is the new native behaviour on BigSur. > > On BigSur the Table rowHeight is 24pt, while on 10.15 it was 17pt: > > https://wiki.lazarus.freepascal.org/ > > macOS_Big_Sur_changes_for_developers#Table_Views > > > > I’m not sure if we should change the default row height. > > With the increased row height text is not vertically centred in Lists and > also in Tree/Table editors. See https://bugzillaattachments.eclipsecontent.org/bugs/attachment.cgi?id=287044
(In reply to Niraj Modi from comment #40) > I’m not sure if we should change the default row height. Even Eclipse itself is not using the taller row height in Trees and Tables, presumably because a font is being set on the control.
(In reply to Phil Beauvoir from comment #43) > (In reply to Niraj Modi from comment #40) > > > I’m not sure if we should change the default row height. > > Even Eclipse itself is not using the taller row height in Trees and Tables, > presumably because a font is being set on the control. Ok, we need to investigate this further. Since the problem is similar as bug 575696, let's close this for 4.22 and track the pending part in bug 575696
