[macOS] some UI elements (e.g. list, tree views) seem to have more space between lines now

[martinlippert]

Some UI elements seem to have a lot more space between lines on macOS since Eclipse 2024-03 builds, for example the package explorer, dialogs showing lists (switch to different perspective), etc. It looks like a very general issue (maybe even in SWT, not sure). Not sure if this was an intended change, but I would prefer the old behavior to save screen real estate.

Eclipse 2024-03-M2 on macOS Sonoma 14.3.1
Plain vanilla EPP package download, empty workspace.

[martinlippert]

This is how it looks like for 2024-03 M2 on macOS:

vs. the overall look using 2023-12 on macOS:

[merks]

Have you tried any of the SWT snippets to see if the problem is like that there too?

[BeckerWdf]

I think eclipse-platform/eclipse.platform.swt#771 is the case for this. And I had the impression that is was by intention.

[Phillipus]

The underlying cause is the macOS SDK version that the Eclipse launcher is built with. In older versions of Eclipse the launcher was built using SDK 10. Later versions are built using SDK 11 and 13. This dictates how the UI elements are displayed. Taller tree and table items are part of SDK 11 and greater. eclipse-platform/eclipse.platform.swt#771 is a fix to keep things consistent.

[martinlippert]

The underlying cause is the macOS SDK version that the Eclipse launcher is built with. In older versions of Eclipse the launcher was built using SDK 10. Later versions are built using SDK 11 and 13. This dictates how the UI elements are displayed. Taller tree and table items are part of SDK 11 and greater. eclipse-platform/eclipse.platform.swt#771 is a fix to keep things consistent.

I tested this using I20240219-0600, which has org.eclipse.swt.cocoa.macosx.aarch64_3.125.0.v20240217-1555. This build still has the described issue. I am not sure whether the fix that got merged in eclipse-platform/eclipse.platform.swt#771 is already included in that I-build though.

[Phillipus]

This build still has the described issue.

Not sure what you mean?

To be clear, since Eclipse 4.30 the launcher has been built using SDK 13 so taller row heights are the norm. eclipse-platform/eclipse.platform.swt#771 was merged on Jan 17 2024. All that patch does is to ensure that row heights stay as they should when a font is set.

[martinlippert]

This build still has the described issue.

Not sure what you mean?

To be clear, since Eclipse 4.30 the launcher has been built using SDK 13 so taller row heights are the norm. eclipse-platform/eclipse.platform.swt#771 was merged on Jan 17 2024. All that patch does is to ensure that row heights stay as they should when a font is set.

I got the impression that the mentioned PR fixes the issue that I illustrated in the screenshots in #1674 (comment), that is why I thought I should re-test the latest I-build and report back here... ;-)

The screenshot above from using Eclipse 2023-12 (4.30) looks like the old behavior though (smaller row height), so it looks like something has changed for 4.31 builds that causes this change.

[Phillipus]

Since Eclipse 4.30 all row heights on Mac are taller by default. Before eclipse-platform/eclipse.platform.swt#771 changing the font of a Table/Tree/List incorrectly added padding of 1 pixel to the row height (wrong). It now adds 8 pixels to match the increased row height. You are seeing smaller row heights in Eclipse 2023-12 because the patch is not present in that version.

The correct row height is the larger one, because of the changes in the SDK.

[Phillipus]

I'll try to make this clearer...

Please take a look at eclipse-platform/eclipse.platform.swt#677

• Since Eclipse 4.30 the x86_64 launcher is built using SDK 13 (has always been the case for Silicon which was built with SDK 11 and now 13) so all row heights are now natively taller (25 pixels instead of 18)
• In Eclipse 4.30 you might see a smaller row height because a padding of 1 pixel was being added to the row instead of 8 pixels when the font was set on the tree/table/list (as in your screenshot)
• This was fixed in Fixing the Item height for Table and Tree when the default font is set eclipse.platform.swt#771 so that all row heights remain consistent at 25 pixels high either before or after changing the font on the control

TL;DR - taller row heights is the new normal.

[Phillipus]

If you want smaller row height you could use -Dorg.eclipse.swt.internal.carbon.smallFonts in your eclipse.ini file.

[martinlippert]

-Dorg.eclipse.swt.internal.carbon.smallFonts

The above screenshot when running on Eclipse 2024-03 M2 is with -Dorg.eclipse.swt.internal.carbon.smallFonts on the eclipse.ini file.

[BeckerWdf]

-Dorg.eclipse.swt.internal.carbon.smallFonts

The above screenshot when running on Eclipse 2024-03 M2 is with -Dorg.eclipse.swt.internal.carbon.smallFonts on the eclipse.ini file.

If you remove -Dorg.eclipse.swt.internal.carbon.smallFonts you should see that you even see less entries on the same screen space in project explorer.

[martinlippert]

Okay, here is a comparison (from the users point of view), first with the smallFonts setting:

A) Eclipse 2023-12 (including -Dorg.eclipse.swt.internal.carbon.smallFonts)

B) Eclipse 2024-03 I-Build (including -Dorg.eclipse.swt.internal.carbon.smallFonts)

The screenshots for both without -Dorg.eclipse.swt.internal.carbon.smallFonts look the same, so posted here just for the reference:

C) Eclipse 2023-12 (excluding -Dorg.eclipse.swt.internal.carbon.smallFonts)

D) Eclipse 2024-03 I-Build (excluding -Dorg.eclipse.swt.internal.carbon.smallFonts)

---

I would actually prefer to continue to have the more compressed look of A) for all my views, lists, tress, etc., but it looks like even setting -Dorg.eclipse.swt.internal.carbon.smallFonts doesn't bring that back. Your comment sounds like B) is the "new normal", but I highly doubt that users would prefer B) over A). Is there a way to bring back the look of A) for those elements somehow?

[Phillipus]

I'll try to explain the situation again (with reference to eclipse-platform/eclipse.platform.swt#677)

• Since macOS 11 native row heights are taller (see comment)
• Since Eclipse 4.30 both x86_64 and Silicon Mac Eclipse have a launcher built using macOS SDK 13 (see comment)
• When a new table/tree/list is created its row height is now taller (see comment)
• However when a table/tree/list has its font or image set it calls setItemHeight (see here )
• Before the latest patch, setItemHeight added vertical padding of 1 pixel which is why you see smaller row heights in Eclipse 4.30. But actually the padding should be 8 pixels to be consistent with the new, taller, row heights which is why it's bigger in Eclipse 4.31

So the new row heights are actually correct for the new macOS SDK.

If -Dorg.eclipse.swt.internal.carbon.smallFonts is set then Tree#setFont() is always called which in turn calls setItemHeight which sets the smaller item height in Eclipse 4.30 but not in 4.31.

• If you remove the -Dorg.eclipse.swt.internal.carbon.smallFonts argument the row heights you see in Eclipse are the new normal for Eclipse on Mac.

[Phillipus]

I would actually prefer to continue to have the more compressed look of A) for all my views, lists, tress, etc., but it looks like even setting -Dorg.eclipse.swt.internal.carbon.smallFonts doesn't bring that back. Your comment sounds like B) is the "new normal", but I highly doubt that users would prefer B) over A). Is there a way to bring back the look of A) for those elements somehow?

Not without creating inconsistent behaviour. If the row height padding in setItemHeight was set back to 1 pixel then any RCP app, or Eclipse itself, that doesn't set -Dorg.eclipse.swt.internal.carbon.smallFonts (which initially forces a call to setItemHeight) would display the larger row height and the next time setFont was called on that control the item height would shrink (as explained here).

To see this, add System.out.println(getItemHeight()); as the first line in Tree#setItemHeight(). This will output 25.

[Phillipus]

The only thing I can think of to maintain backward compatibility would be to use a vertical padding of 1 pixel if -Dorg.eclipse.swt.internal.carbon.smallFonts is set and 8 otherwise.

[Phillipus]

Please comment and test eclipse-platform/eclipse.platform.swt#1055

The caveat with this is that -Dorg.eclipse.swt.internal.carbon.smallFonts forces a call to setItemHeight which sets the row height smaller. The native initial row height is actually larger (25).

[martinlippert]

The only thing I can think of to maintain backward compatibility would be to use a vertical padding of 1 pixel if -Dorg.eclipse.swt.internal.carbon.smallFonts is set and 8 otherwise.

Yeah, I had the same thought, that would be awesome.

[Phillipus]

The only thing I can think of to maintain backward compatibility would be to use a vertical padding of 1 pixel if -Dorg.eclipse.swt.internal.carbon.smallFonts is set and 8 otherwise.

Yeah, I had the same thought, that would be awesome.

@martinlippert Can you test eclipse-platform/eclipse.platform.swt#1055?

[martinlippert]

The only thing I can think of to maintain backward compatibility would be to use a vertical padding of 1 pixel if -Dorg.eclipse.swt.internal.carbon.smallFonts is set and 8 otherwise.

Yeah, I had the same thought, that would be awesome.

@martinlippert Can you test eclipse-platform/eclipse.platform.swt#1055?

Yeah, happy to give this a try. Any recommendations about the easiest way to build this locally?

[Phillipus]

Any recommendations about the easiest way to build this locally?

You need to clone https://github.com/eclipse-platform/eclipse.platform.swt and import the org.eclipse.swt and binaries/org.eclipse.swt.cocoa.macosx.aarch64 projects into your workspace. You also need to fetch and checkout the PR.

[merks]

@martinlippert

Using https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#creating-an-eclipse-development-environment fully automates the setup process.

It's a bit of overkill because it includes everything in the SDK, but it lets you launch a runtime workspace (launcher provide) where you can see the impact in context.

You can also go back:

Deselect everything:

And select only SWT:

[Phillipus]

The only thing I can think of to maintain backward compatibility would be to use a vertical padding of 1 pixel if -Dorg.eclipse.swt.internal.carbon.smallFonts is set and 8 otherwise.

Thinking about this more, this workaround is not really true to the intent of the org.eclipse.swt.internal.carbon.smallFonts setting.

With the workaround patch:

• If smallFonts is not set the default font is .AppleSystemFont 13 and row height padding is 8 pixels.
• If smallFonts is set the default font is .AppleSystemFont 11 and row height padding is 1 pixel
• However, in the case where smallFonts is not set and the user sets a control's font to .AppleSystemFont 11 the row height padding is 8 pixels.

So with this patch we're effectively changing the meaning of the smallFonts setting to mean "use a smaller font and use a small row height". If we are to be true to the native OS, then really the larger row height should be used in all cases.

[merks]

I'm not on a Mac but if this issue were Windows I would be super annoyed to suddenly have a lower density of information content in all my views.

@martinlippert

Are other places (other native mac applications) also showing such less dense tables, tree, and lists?

[Phillipus]

I'm not on a Mac but if this issue were Windows I would be super annoyed to suddenly have a lower density of information content in all my views.

But this was actually the case for all native Mac apps when macOS Big Sur (11) was released. Since then native row heights on Mac are increased (if they target the later Mac SDK), as noted here.

I've spent a lot of time thinking about, and experimenting with, this issue and have come to accept this as the new normal. In our RCP app, Archi, we don't set the org.eclipse.swt.internal.carbon.smallFonts setting. Thus, all row heights are now larger on later macOS. We can't change that, it's native, and SWT creates these controls with that increased row height. The problem for us was that controls had the larger row height but if a user changed the font for a control, it magically shrank the row height (because of the 1 pixel instead of 8 pixels in setItemHeight).

[Phillipus]

Are other places (other native mac applications) also showing such less dense tables, tree, and lists?

Yes. Even the SWT-based app "SmartGit".

Before:

After:

To be clear, if you don't use the org.eclipse.swt.internal.carbon.smallFonts setting and run Eclipse 4.30 on the latest macOS you'll see the increased row height (except for a few owner-draw tables and trees). This is the native row height. This Snippet proves this.

[BeckerWdf]

If we are to be true to the native OS, then really the larger row height should be used in all cases.

I can only second that. The operating system dictates how the high a line in a tree is. We should not try to circumvent this.
I think it's just a matter of what you are used to. When I first saw the differences I also thought that the old one was better. But the longer I see the new one I find the old one wrong - it's just too packed and too less whitespace.

[exabrial]

Just wanted to report back no issues with the hotfix initially! @Phillipus thank you for guiding the discussion onto the right track and @kohlschuetter for providing the code. Very much appreciated.

[MahatmaFatalError]

So, 76 comments later, what is the conclusion for the just released 2024-03 ?

[martinlippert]

I think the fix will be part of the 2024-06 release. If you want to fix this in a running 2024-03 installation, I would follow the steps described in #1674 (comment). Worked for me quite nicely.

[ptrussart]

Is there a way to have a fix for the x86_64 Mac processor ?

[laeubi]

I just wanted to note that putting arbitrary "hotfix jars" downloaded from the internet into your eclipse folder can impose server security risk to your eclipse installation, therefore I would recommend to either build it locally yourself or use the official I-builds:

https://download.eclipse.org/eclipse/downloads/

The integration builds will also contain SWT jars you can replace then in your installation.

[Sciuriware]

Like to add: "Haste makes waste"
;JOOP!

[kohlschuetter]

I personally would not recommend anyone to upgrade their stable Eclipse release to an integration build with probably hundreds of unrelated changes.

@merks @lshanmug Can we please get an official release for the fix, without having to update to an unstable integration build?

Furthermore, I get the whole xz/liblzma story may cause some folks to go extra paranoid but I want to set things straight here:

I by myself built and provided the jar built from the code I wrote myself in the PR. The PR and jar is hosted on github.com. I use my real name in these communications, and with that I hopefully still have a reputation to lose.

@laeubi:

I feel that you calling this work an "arbitrary hotfix jar downloaded from the internet" that "can impose server security risk to your eclipse installation", is an insult to outside contributors like me, and a disservice to all open source contributors that act in good faith. I have attached the jar to this patch solely to help people in the moment, and I think you know that.

On that note: I may also remind you that before this fix I have also fixed eclipse-m2e/m2e-core#1511 which was broken by a change that you introduced yourself almost a year before, and it was probably not fixed earlier because you (erroneously) claimed that another upstream bug was to blame. Since I see a pattern here, maybe you should lower your accusing tone a bit?

I have spent numerous hours chasing both bugs and patiently followed up getting these fixes in so others can also benefit from my findings. Please, without diverting into the general case, have at least the decency to respect my contribution in good faith, or show us objective proof that my hotfix jar is a security risk.

As to this date, updating Eclipse from within its own app occasionally shows me unsigned plugins that either have to trust blindly or not install at all, because the existing landscape of Eclipse plugins, integration build update sites and the Eclipse marketplace are a shit show by themselves.

I mean, even for the signed plugins, I can't really tell the quality of a release, especially when obviously visible bugs like this present one don't qualify for a rather immediate patch release.

This is something you should look into before starting the scaremongering.

[merks]

The next official release is in June. So unfortunately folks need to wait until that release or consume integration/milestone builds to get it sooner. The release engineering effort to produce a release of the platform is already daunting. Backporting the fix to the 4.31 maintenance branch is feasible but you will notice that there are no published builds for that stream Providing a fix for just this issue for the IDE packages on the download server just doesn’t seem feasible logistically.

You certainly have my gratitude and respect for helping to resolve this bug. It’s effort beyond the call of duty. If even 1 in 10,000 were this helpful, we’d be flooded in riches. ❤️

[kohlschuetter]

Thanks a lot @merks, I appreciate your kind words.

[laeubi]

I personally would not recommend anyone to upgrade their stable Eclipse release to an integration build with probably hundreds of unrelated changes.

No one needs to upgrade their whole "stable Eclipse Release", Eclipse installations can perfectly run side-by-side. Also this integration builds will become the next release so if people would test these beforehand one probably would identify the one of the hundreds maybe surprising or even harmful changes before the release what would prevent such "after the fact" discovery that is hard to fix as @merks has mentioned.

Beside that I never claimed your patch / jar is harmful, nor did I insulted / addressed you in anyway.
It was just a general warning because in this thread people seem to tend to recommend this practice and there was even a follow up request for another patch-jar. And what if now I would upload such a patch x86_64 Mac processor to github then people will probably using it because it was done so in the past. If that ever happens please don't do that! My computer might be compromised, my github account might be hacked, someone created an account that looks similar to mine, or whatever else.

This simply bypasses even the most basic checks we have in Eclipse/P2 and has nothing to do with being paranoid or scaremongering. Also this does not mean your contribution is bad in anyway or not appreciated.

[martinlippert]

Also this integration builds will become the next release so if people would test these beforehand one probably would identify the one of the hundreds maybe surprising or even harmful changes before the release what would prevent such "after the fact" discovery that is hard to fix as @merks has mentioned.

I fully agree to this, but I also feel the need to mention that I discovered and reported this specific issue before the release (using M2). So this was not a discovery after the fact ;-)

[laeubi]

Also this integration builds will become the next release so if people would test these beforehand one probably would identify the one of the hundreds maybe surprising or even harmful changes before the release what would prevent such "after the fact" discovery that is hard to fix as @merks has mentioned.

I fully agree to this, but I also feel the need to mention that I discovered and reported this specific issue before the release (using M2). So this was not a discovery after the fact ;-)

Yep and it was worked on so everything is fine for me, it was also more a general comment and directed to the "probably hundreds of unrelated changes", the more people test it the earlier they we detect problem, the more likely one gets a fix / better quality in release.

So from my experience ibuilds are very stable or if there is a problem are fixed sometimes even withing hours, so if I'm affected by a bug introduced in a release I can either stay at the old or use the just fixed ibuild and see if something else will affect my workflow.

[martinlippert]

Until the fix from eclipse-platform/eclipse.platform.swt#1117 is merged, feel free to try this binary as a hot fix (copy to /Applications/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.swt.cocoa.macosx.aarch64_3.125.0.v20240227-1638.jar or wherever you placed your Eclipse app).

The jar in hotfix.zip should replace the existing jar with the exact same name.

hotfix.zip

Hey @kohlschuetter, can you explain to me how you've exactly built this hotfix? I would like to run that myself, so in case you have the command that you used at hand or can share the script (or whatever you used), that would be awesome. Many many many thanks upfront!

[kohlschuetter]

@martinlippert If I remember correctly, it's just a matter of running mvn clean install -DskipTests on my branch of eclipse.platform.swt.git and then cp binaries/org.eclipse.swt.cocoa.macosx.aarch64/target/org.eclipse.swt.cocoa.macosx.aarch64-3.126.0-SNAPSHOT.jar /Applications/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.swt.cocoa.macosx.aarch64_3.125.0.v20240227-1638.jar (replace aarch64 with x86_64 if necessary)

Please work with code obtained via git checkout 611accb844fb525efb3727f7fe8e2e7a3472debf from https://github.com/eclipse-platform/eclipse.platform.swt.git. Note that the PR has evolved since the hotfix version (properties have been renamed etc. ) so you will not get exactly the same binary.

[HannesWell]

I personally would not recommend anyone to upgrade their stable Eclipse release to an integration build with probably hundreds of unrelated changes.

In case you are concerned that for example https://download.eclipse.org/eclipse/updates/4.32-I-builds/ is a changing repository, instead of using the composite one can just use one of the immutable children (but they vanish after the next release):
https://download.eclipse.org/eclipse/updates/4.32-I-builds/I20240330-1800/

[kohlschuetter]

@HannesWell

Thanks for the tip! That could be another option. (It would be great though to know which build contains which commits — it's not obvious to me where to find that information)

I think there's a more of a general problem with switching from a stable release to bleeding edge development.

For example, I'm pretty sure my Eclipse workspace will become incompatible, so downgrading will suddenly become unnecessarily difficult. Then, there's potential unexpected fallout due to new bugs, etc.

This is all nothing new, not to me, and not in general (I have contributed to and survived living on "next major OS" releases for several years, and dogfooding is necessary for any serious project).

It's just that there are "regular" Eclipse developers that don't consider themselves developers of Eclipse but simply developers using Eclipse, and they should certainly be able to just stick to the regular stable channel.

As @merks commented above, I now understand that shipping a patch for a botched release isn't something trivial at the moment for the Eclipse IDE project. I wonder if that situation merits some attention from project management.

Any thoughts? (follow-up maybe on a separate issue?)

[HannesWell]

It would be great though to know which build contains which commits — it's not obvious to me where to find that information

For each I-build the commit build of each sub-project is tagged with I-<build-id>. So you from the interesting commit you can just check the next one tagged (maybe even that commit) and look for the matching I-build.

As @merks commented above, I now understand that shipping a patch for a botched release isn't something trivial at the moment for the Eclipse IDE project. I wonder if that situation merits some attention from project management.

Any thoughts? (follow-up maybe on a separate issue?)

It's a somehow known issue but I don't think one that can be generally solved soon.
The release process is complex and although there is steady work to simplify it, it will certainly take time.
This is also a point discussed for example in
eclipse-pde/eclipse.pde#1136 (comment)

But besides the man-power there are also technical difficulties for projects that are more or less a root of the decency tree like SWT. Due to the way for example features work a new version of SWT means that all features including it and the features including those features need new builds because versions are locked in features.
Otherwise the new version is not considered by you installation (which is usually based on features).
In unfortunate circumstances this could mean that many features in the entire SimRel would need to be rebuilt.
We are working on using features more 'precisely' but it is a long journey and not all projects in the SimRel are eager to go it.

[merks]

FYI. On my todo list is to investigate how best to allow EPP packages, as on the main download page, to update to any new platform build, including I-builds. It’s annoying when a problem in a simrel milestone or a release cannot be updated until there is a new simrel milestone. And I think it’s an avoidable annoyance.