Thanks for this! Do we also need to do something to ensure a minimum sidebar width to fit the tabs without abbreviation of tab names?

On a MacBook Air with 200% HiDPI scaling, the sidebar needs about 25% of the screen width to avoid abbreviation.

EDIT: To answer my own question, the current default sidebar width is in ide/spi.navigator/src/org/netbeans/modules/navigator/resources/navigator.wsmode , which is 30%. That should be enough.

I think this should probably be open by default unless ergonomics is in play, and the logic for opening with files handled in there?

I think this should probably be open by default unless ergonomics is in play, and the logic for opening with files handled in there?

not completely sure what open by default means. If you mean to open it on first launch without any trigger, I thought about it and tried it, but it looks weird next to the welcome page. Your comment at#8744 (comment) sounded like you don't like that idea either so I didn't even mention it in the dev list discussion thread.

Sorry, a wrong assumption on how this was handled based on long time platform projects that have obviously overridden the defaults.

If it behaves similarly to Project and Files, both with or without ergonomics, all good!

the current default sidebar width is in ide/spi.navigator/src/org/netbeans/modules/navigator/resources/navigator.wsmode , which is 30%. That should be enough.

oh wow. I was actually searching for that. For some reason I didn't make the connection that the west column is called navigator. I assumed thatwindowmanager.wswmr would set the initial layout, but editing numbers there did nothing.

I wanted to reduce that value to give the editor more space. Its unfortunate that it only supports relative values for initial sizing.
30% for a side panel is already too large for regular 1080p (its almost 600px wide) - this is going to be worse on higher resolutions.

25% would still work on 720p according to my measuring stick, assuming the window is maximized first. Should we change it?

btw the optimal value for 1080p would be ~16% when maximized,half of the current width ;)

made two changes:

• addedwasOpened() check to take the scenario into account when a user closes it right after opening the first project, in that case it should not open again after the first file is opened
• made west column 5% smaller for testing purposes (still too large IMO)

25% would still work on 720p according to my measuring stick, assuming the window is maximized first. Should we change it?

Do MacOS users normally maximize their windows? I had to install a special window tiler app (SizeUp) to make maximization easy... otherwise if you press the green window button thing it just goes into a very useless full screen mode thing.

In my platform app I have special code for maximizing the window on startup. But the "out of the box" experience for the NetBeans IDE might well be the narrower unmaximized state.

Do MacOS users normally maximize their windows?

I don't know, but I had raspi users and embedded in mind for the 720p scenario. For mac even the windowed mode will be larger than 720p. On 1920x1080 NB opens as ~1700pix wide window where 25% is already wider than necessary.

I'm a little sceptical at adding a taband lowering the width in the same PR if you're targetting freeze. At least one system I tested on the mailing list thread was fairly tight with all four. UI scaling also has an impact. OTOH, the width can always be put back in at a later RC I guess. 😄

EDIT: Mind you, has this changed? Does this not also depend onhttps://github.com/apache/netbeans/blob/master/platform/core.ui/src/org/netbeans/core/ui/resources/windowmanager/explorer.wsmode (platform) andhttps://github.com/apache/netbeans/blob/master/ide/projectui/src/org/netbeans/modules/project/ui/resources/explorer-override.wsmode (IDE) ?

I'm a little sceptical at adding a tab and lowering the width in the same PR if you're targetting freeze.

Agree with this.

For making the sidebar narrower, I think it would be better to add a feature to the window system to allow a constant pixel width to be specified as the initial default. (EDIT: Exactly how to do this might need some more thought. What happens if a constant width is specified initially and then the window is then resized etc.)

going to revert the 5% reduction. Please be specific while reviewing or discussing. I heard that several times that the sidebar doesn't fit the tabs, but couldn't reproduce it even once. In all realistic cases it was too large or far too large (like the 1080p case). Matthias did try to reproduce the issue too during the discussion on the dev list since it was mentioned there too and he couldn't either. Lets not waste all our time by being so vague.

Here's how a fresh NetBeans installation (deleted user dir) would open on a 2024 MacBook Air with 200% HiDPI scaling, if Favorites is open and the the default sidebar width was 25% instead of 30%:

The window does in fact not maximize by default on MacOS.

thanks for testing! The long term solution would be likely setting fixed initial sizes in px (as mentioned before), but they would have to scale with the UI scaling factor.

25% on 1080p looks nearly half empty. So it makes sense that when scaled 2x it would be slightly too small (not accounting for different fonts and other factors which might ask for more wiggle room). (this PR reverted to 30% again, making no changes to the layout)

The long term solution would be likely setting fixed initial sizes in px (as mentioned before), but they would have to scale with the UI scaling factor.

There are a couple of different UI scaling factors at work. The HiDPI scaling from the operating system would not impact the minimum width, as Swing operates in "logical" pixels rather than device pixels. NetBeans properties such as "fontsize" and flatlaf.uiScale would affect the minimum width needed to avoid abbreviation, but for the cases where people are tweaking those, I think it would be fine to just require those users to adjust the sidebar width manually.

The reason I mentioned HiDPI scaling is because it affects the logical screen resolution available to apps. It's the setting shown here:

My conclusion: If a minimum width in "swing" pixels could be specified for the sidebar, that would solve the problem.

My conclusion: If a minimum width in "swing" pixels could be specified for the sidebar, that would solve the problem.

right. That is what I mean since swing pixels do scale already. The west column needs about 350 pixels right now (includes extra wiggle room for fonts) when scaling is disabled. For 200% scaling it would need about twice as much, but the scaling factor itself would do that already.

a platform test is failing. will investigate.

see#8915

Thanks for doing this!

Just because I've only just had a chance to follow up ...

Please be specific while reviewing or discussing. I heard that several times that the sidebar doesn't fit the tabs, but couldn't reproduce it even once.

Me neither, although the machine I'm using now while travelling is tightest. It's an Arm Chromebook - native resolution is actually 1920x1200, but the default (and good for my eyes!) is scaled to 1440x900. That can actually go to 24% before the tabs don't fit. That does assume no project group is set though, and this does cover reset windows as well as first run.

If you come back to this then the twoexplorer.wsmode files should probably be kept in sync with any change. Curiously, the value fromnavigator.wsmode does seem to be used whether smaller or bigger - would expect maximum of the two - not sure if that's a bug.