[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.

[lshanmug]

Thanks @Phillipus for the detailed description about the new behavior.

The increased row height for Table/Tree is the new default behaviour that was introduced with macOS BigSur (in Nov 2020). So, SWT applications/snippets on aarch64 were already seeing increased row height since then. For example, https://bugs.eclipse.org/bugs/show_bug.cgi?id=575696. Eclipse by default was kind of shielded from this change so far because it had -Dorg.eclipse.swt.internal.carbon.smallFonts specified in the eclipse.ini which controls the font size. However, even with older Eclipse builds, launching the child eclipse had the taller rows as the launch config doesn't have -Dorg.eclipse.swt.internal.carbon.smallFonts specified.

Looks like with the fix for https://github.com/eclipse-platform/eclipse.platform.swt/issues/677#, -Dorg.eclipse.swt.internal.carbon.smallFonts has lost it's 'special effect' on the row height. I've not looked into the code in detail to see how it can be done, but if we can retain the effect of the smallFonts property things could be same as before from both Eclipse and SWT POV.

@Phillipus Please correct me if I'm missing something in my comment.

[soethoff]

macOS dev here: I always used the -Dorg.eclipse.swt.internal.carbon.smallFonts parameter (I think it's set per default, at least for the Java Developers package), so even on aarch64 I didn't see any change, until now.

It's rather late in the development cycle to suggest yet another system property, and if we don't do that this release cycle, everyone will just get used to it such that changing it again would be kind of strange.

Agree, first I was confused, now I got used to and would prefer to keep it 'native'. It's now behaving the same as other IDEs like VSCode or IntelliJ (excluding Xcode or Finder), at least when still using the -Dorg.eclipse.swt.internal.carbon.smallFonts parameter. I also have the feeling, that it looks now more 'natural', but sure, this is very personal.

If there is the wish to have something like this configurable, it might make sense to offer some new appearance option like macOS does (system settings -> more space / bigger letters). In that way the overall look & feel adjusts to the wished / needed scaling and not only the font size nor the padding.

I agree. My vote is to not merge the draft PR I created.

I also like to vote to not merge the draft PR. My understanding would be that with this change it would not be possible anymore to have the 'native' padding and small fonts at the same time.

[Phillipus]

Thanks for the feedback @lshanmug your analysis is correct. In fact the reason why we only saw increased row height in aarch64 Mac version and not x86_64 version was not because of the architecture difference but because the aarch64 launcher was built with Mac SDK 11 and the x86_64 version launcher was built with Mac SDK 10. Now that both launchers are built with SDK 13 the row height increase is present in both versions.

Therefore, the increased vertical padding of 8 pixels in the setItemHeight method is absolutely correct in all cases to maintain consistency and to stop row heights magically shrinking when the font is set. See my comment here.

This idea from @soethoff seem more in tune with the intent:

If there is the wish to have something like this configurable, it might make sense to offer some new appearance option like macOS does (system settings -> more space / bigger letters). In that way the overall look & feel adjusts to the wished / needed scaling and not only the font size nor the padding.

org.eclipse.swt.internal.carbon.smallFonts should mean just that, use a smaller font (I think its font height 11 instead of 13), not remove additional native padding.

I also like to vote to not merge the draft PR. My understanding would be that with this change it would not be possible anymore to have the 'native' padding and small fonts at the same time.

Exactly.

When Apple released Big Sur 11 they defined new UI metrics.

[Phillipus]

POC idea to add (yet another ;-) ) startup option for smaller item (row) heights. This one is separate to the smallfonts option and so it would be possible to have the 'native' padding and small fonts at the same time.

https://github.com/eclipse-platform/eclipse.platform.swt/pull/1057

[a1dutch]

I've just updated to Eclipse 2024-03 and the extra whitespace is not nice in the package explorer especially

[Phillipus]

I've just updated to Eclipse 2024-03 and the extra whitespace is not nice in the package explorer especially

The reason why item heights are larger has been made clear several times in this thread. The underlying cause is due to Apple's changes to native UI elements since Big Sur. A bug fix in SWT now corrects the true item height when the font is set so that they are in line with the true native height.

What we can't have is a Tree/Table/List starting out with the increased item height when it is created and then magically shrinking when the font on that control is set. Eclipse IDE users don't see the initial larger row height because of the org.eclipse.swt.internal.carbon.smallFonts setting forcing the smaller height after creation when setFont is called (a bug), but you will see the larger heights in an RCP app or debugged child Eclipse when it is not set.

[kohlschuetter]

I just updated to 2024-03 on macOS and also very much noticed the increased line height.

I have a lot of projects open at the same time, and I rely on the high information density as it was with Eclipse 2023-12 and before.

Adding this line space reduces the chance that I immediately see certain project warnings (yellow icons in the Project Explorer). I also have to scroll more, which makes me very sad.

The argument I read so far is "it works as expected because Apple decided so in an SDK change, and we now happen to use the new SDK".

I totally understand the rationale for following UI guidelines for regular UI elements such as settings.

However, as a user, I would like to be able to customize the appearance to my needs, and it looks like whatever reason the change in 2024-03 is, to me it is a regression.

Notably, even Apple themselves don't follow these rules themselves blindly. Take Xcode as an example. They support three levels of spacing "Normal" but also "Tight" and "Relaxed", at least for the text editor.

For the project/source code explorer view, Xcode also seems to be able to show 13pt fonts in the same height as Eclipse does for 11pt fonts. (If you increase Eclipse's font size in "Tree and Table font for views" to 13pt, the height is a few pixels larger than Xcode for the same font size).

[Phillipus]

@kohlschuetter You need to understand the real reason (made clear in this thread several times) about why this change was made.

When SWT creates a new Table, Tree, or List it is created natively with the increased row height (because it is using macOS SDK 11 or greater). It is a side effect and bug that when the option org.eclipse.swt.internal.carbon.smallFonts is used it forces a call to setItemHeight which used to add an (incorrect) padding of 1 pixel, hence the smaller row heights. To maintain consistency with the initial row height the correct padding is now set to 8 pixels. Without this change, an RCP app or SWT-based app that creates one of these components will initially display with the larger row height and will then shrink later whenever setItemHeight is called.

Not all apps (and launching child Eclipse) use the org.eclipse.swt.internal.carbon.smallFonts setting and so even before this change there were increased row heights (in Eclipse 4.30 remove the org.eclipse.swt.internal.carbon.smallFonts setting from the eclipse.ini file and see the row heights are bigger)

The issue is to maintain consistency between the initial row height when a control is created, and when setItemHeight is called.

I have proposed a new option for smaller row heights here.

[merks]

As we see, however correct it may be, users perceive it as different and not better. 😞

[exabrial]

As we see, however correct it may be, users perceive it as different and not better. 😞

UI issues are frustrating in that regard, as it's difficult to separate preference vs performance. From my perspective, being able to see roughly 1/3 the information I used to be able to, and instead stare at blank space, is a regression. Being reasonable and after reading through this thread, I'm willing to admit that this could be "preference" however.

It would be a great relief to make this a configuration item for those who prefer more information on their screen.

As always, thank you Eclipse Team, happy Eclipse user here. I'm happy to help any way I can.

[merks]

@exabrial

That a super nice way to express it! If only more people were so reasonable, understanding, and nice. ❤️

[Phillipus]

As we see, however correct it may be, users perceive it as different and not better. 😞

And I agree with that. But we have to find a solution that fixes the discrepancy in initial row heights as created by SWT and the "magical shrinkage" that can occur later, and also provide a means to restore the older item heights.

The padding used in setitemHeight has to match that of the control's row height when it is created. Otherwise we get "magical shrinking" of row heights. Either these controls are initially created with a smaller row height or a bigger row height and that row height is maintained when setitemHeight is called. Like it or not, the old way led to this bug.

What I'm saying is this:

If Mac users want the smaller row height then it should be set when a Tree/Table/List is initially created, not "magically shrunk" by chance if and when setitemHeight is called. This PR does that.

So, we need to address two concerns:

1. Maintain consistency of row height when a control is created and when setitemHeight is called
2. Either use small row heights or native macOS row heights, or add an option to use either of these

[kohlschuetter]

@Phillipus Thanks for providing the patch! I tried it and also experimented with different values for that vertical cell padding.

The smallest value that made a difference for my 11 point default font was 3 (not 1), bringing back what looks like the original line spacing. 5 looked actually not too bad, and the default 8 is definitely too large to me.

Concerning the bug in #677 (setting the same font again reduces item height), do I understand correctly that this is mitigated by setFont((Font)null); in your patch? If not, would setting VERTICAL_CELL_PADDING to 3 fix it?

Moreover, we could actually use a factor for that "vertical cell padding" instead of an absolute value, because it's actually just a line "leading" property (which should be around 20-30% of the font size. That way, it will work correctly for larger font sizes, too (a factor of 1.2 is like the old behavior; 1.35 looks still OK for all sizes and appears to result in the same spacing as the project explorer in Xcode with font size 13pt)

[Phillipus]

Concerning the bug in https://github.com/eclipse-platform/eclipse.platform.swt/issues/677 (setting the same font again reduces item height), do I understand correctly that this is mitigated by setFont((Font)null); in your patch? If not, would setting VERTICAL_CELL_PADDING to 3 fix it?

Calling setFont((Font)null); in List and setItemHeight in Table and Tree sets the item heights in the constructor so that they are consistent.

Please note, as I keep trying to emphasise, the problem is fixing the discrepancy between the initial item height when a control is created and the item height calculated in setitemHeight (or setFont in the List control)

we could actually use a factor for that "vertical cell padding" instead of an absolute value,

I tried that and it led to differing results between the native initial item height and the one calculated in setitemHeight. Perhaps it needs some fine tuning.

[Phillipus]

I really don't know how I can make the issue clearer. I must have have explained it here and in other issues perhaps 20 or so times? What part do people not understand? (Genuine question, not sarcasm).

[kohlschuetter]

@Phillipus I think the mismatch in our communication is

1. what users like me describe as a problem here (call it the "too much space problem") and
2. what you refer to as the problem (the problem that was addressed with the patch for #677, which caused the visual regression — call it the "height gets smaller problem").

These appear to be two different problems. I haven't seen problem 2 myself, but I'm not sure I would agree that hard-coding an additional 7 pixels for padding sounds like a proper solution either. It feels like there's more to that to understand what's going on.

I looked into your demo code in #677 and tried to reproduce the bug on my machine (macOS Sonoma 14.4 (23E214) MacBook Pro M1 Max).

To do so, I created a new Java project, linking org.eclipse.jface_3.33.0.v20240214-1640.jar from Eclipse 2024-03 and then either Eclipse's org.eclipse.swt.cocoa.macosx.aarch64 jar or the SNAPSHOT one from git (using eclipse.platform.swt branch R4_31, applying your POC commit on top of that), and using a -Djava.library.path=/Applications/Eclipse.app/Contents/Eclipse/configuration/org.eclipse.osgi/2599/0/.cp for the native dylib. For the SNAPSHOT builds I tested both with and without -Dorg.eclipse.swt.internal.cocoa.smallItemHeight

I clicked on the "Set font" button, but in all three cases the table item height did not change.

The only difference in the three runs being the height itself (18 with snapshot and -Dorg.eclipse.swt.internal.cocoa.smallItemHeight, 25 otherwise).

Adding -Dorg.eclipse.swt.internal.carbon.smallFonts also didn't trigger the bug for me, resulting a font height of 22 (15 with smallItemHeight)

Could it be that you are seeing a problem that was introduced and then subsequently fixed in Cocoa/AppKit?

If so, why bother? The cure is much worse than the disease, so to speak.

[Phillipus]

I clicked on the "Set font" button, but in all three cases the table item height did not change.

(The link to that issue is actually https://github.com/eclipse-platform/eclipse.platform.swt/issues/677)

Yes, because that was fixed here and so you won't see the problem unless you use an earlier version of SWT. And that fix leads us here...

Could it be that you are seeing a problem that was introduced and then subsequently fixed in Cocoa/AppKit?

No. Please read all of my analyses here.

[Phillipus]

Either revert https://github.com/eclipse-platform/eclipse.platform.swt/commit/0032340b9b647db3ef6776d6b2e481397bd74b8d (and go back to inconsistent and broken behaviour) or follow through with a solution that attempts to maintain the current consistent behaviour and also provides an option for smaller item heights as well as native item heights as proposed here. i.e. solves both issues.

[kohlschuetter]

OK, I reverted eclipse-platform/eclipse.platform.swt@0032340, and I can reproduce the "height gets smaller problem".

Then I added setItemHeight(null, null, true); to the Table constructor (like what you did in the POC code, sans the configurable padding logic), i.e.

public Table (Composite parent, int style) {
    super (parent, checkStyle (style));

    setItemHeight(null, null, true);
}

and the item height reliably stays at 18 when I click "Set font"

The list looks OK visually, isn't that all we need?

I understand you also want to be able to support whatever "native" item heights are, but obviously that number depends on some SDK version and is not relevant to any previously working Eclipse app.

Maybe that "feature" can be indeed configured separately? For example, you could simply retrieve the native height in the constructor, via ((NSTableView)view).rowHeight() (which returns 24 instead of 17 on my M1 Mac) and use that as a "minimal height" constraint that can be enable/disabled independently...

Now back to the "Project Explorer looks bad" problem: Yes, you could make that "set minimal height to system default" the default case for Eclipse IDE (maybe via a boolean System property enforceNativeHeights=true or something like that), adding an exception for the Project Explorer (and all other places that matter), allowing whatever value setItemHeight determines today. That way, all other system UI in Eclipse, like the Preferences etc., will retain the "native macOS look". Is that more like what you want?

[Phillipus]

The list looks OK visually, isn't that all we need?

No.

The native (and correct) item height for the control is the larger one when it is first created. When setItemHeight is called it made it smaller in pervious versions because of the 1 pixel padding. In 4.31 a correct 8 pixels of padding is used. This is the correct behaviour. The aim is to maintain the same item height when the control is created and when setItemHeight is called.

If people want the smaller item height then it has to be set both in the control's constructor and in setItemHeight. This should be optional so that Eclipse and RCP apps can use the native item height.

• Get a copy of Eclipse 4.30 for Mac (i.e before this change )
• Launch Eclipse 4.30 to see small item heights
• Edit the Eclipse.app/Contents/Eclipse/eclipse.ini file and remove the -Dorg.eclipse.swt.internal.carbon.smallFonts setting
• Launch Eclipse again to see larger item heights

The smaller heights are a side effect of the -Dorg.eclipse.swt.internal.carbon.smallFonts setting calling setItemHeight. Many RCP apps don't use this setting and so get the native, bigger, row heights.

[exabrial]

Phillipus thank you for taking the time to help everyone work towards the most correct solution. Sorry it's frustrating!

[Phillipus]

Phillipus thank you for taking the time to help everyone work towards the most correct solution. Sorry it's frustrating!

Thanks.

I'm going to make yet another attempt to explain the situation...

1. Some time ago, Eclipse for Mac was compiled/linked to macOS 10 and so the native row heights were small when these controls were instantiated.
2. Now that Eclipse for Mac is compiled/linked to macOS 13 the native row heights are larger to match the UI of the linked macOS SDK.
3. After (2) Eclipse users continued to see small row heights because of the (incorrect) 1 pixel padding applied when setItemHeight was called (triggered by -Dorg.eclipse.swt.internal.carbon.smallFonts and setFont).
4. However, this 1 pixel padding didn't match the initial native row height when the controls where instantiated and was changed to 8 pixels in a recent fix that made it into Eclipse 4.31 (see here)
5. After the fix in (4) Eclipse users now see the larger row heights because of this padding correction. (They would have seen these larger row heights before if -Dorg.eclipse.swt.internal.carbon.smallFonts was not applied)
6. Users don't like the (technically correct) increased row heights

So, the way forward is to:

1. Maintain the same row height height when a control is instantiated and when setItemHeight is called
2. Provide a way for the row heights to be small (old behaviour) and native sizes (macOS UI behaviour)

[kohlschuetter]

@Phillipus Please take a look at my pull request. I hope I've covered all cases. Notably, the change does not make any assumptions about the vertical padding being 8, it just enforces the default height as the minimum if required. This also means we don't have to tune any parameters, and even retain compatibility with older, future, and unexpected macOS settings.

I verified the patch with your TableFont test, and I consistently get an item height of 25 with no configuration on newer macOS (and likely 18 on older macOS), an item height of 15 with (-Dorg.eclipse.swt.internal.carbon.smallFonts, as Eclipse IDE has by default, bringing back the expected behavior from 2023-12 and before), or a height of 18 for those folks who want the old macOS behavior back but don't want smallFonts.

Did I miss any scenario?

https://github.com/eclipse-platform/eclipse.platform.swt/pull/1117

[Phillipus]

@Phillipus Please take a look at my pull request. I hope I've covered all cases.

https://github.com/eclipse-platform/eclipse.platform.swt/pull/1117

This is now the PR that is being worked on to come up with a solution, thanks to @kohlschuetter

[kohlschuetter]

Until the fix from https://github.com/eclipse-platform/eclipse.platform.swt/pull/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

[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 https://github.com/eclipse-platform/eclipse.platform.ui/issues/1674#issuecomment-2001986963. 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 https://github.com/eclipse-m2e/m2e-core/issues/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 https://github.com/eclipse-pde/eclipse.pde/issues/1136#issuecomment-2033131726

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.