The SplitView already supports layout priorities. Could the EditorPart fix this by using layout priorities? Eg: when a view is maximized, set its priority to High.

Thanks for the quick review, @joaomoreno.

There is no setter for priority. I could add one and update GridView.maximizeViewSize to set the priority, but then I'd need to reset the priority on the other views here:

However, I don't think I can set it back to LayoutPriority.Normal because I don't know if that was the original setting. I can add another variable for the initial setting, but that's another variable to store. Even after that, I don't think setting the priority work because the priorities are used in the following flow, but in this case, we already have proportions:

So I think I'd still need to update the following anyway:

It's possible that I could revert adding the following code if I set the priority.

However, I'm not sure if it's worth having to add a getter and save the original priority. What do you think?

The grid/splitview can't modify priority, they only read the value. The views themselves set it. The user of the grid (EditorPart) would coordinate across its views and set their priorities accordingly.

But on second thought maybe that's too crazy. Let's tackle both issues individually and start with #70083 first.

The maximized state isn't preserved across layout calls. If we fix it, we don't want to change the default spltiview behavior, but add/modify an option. What if we have a different type for proportionalLayout? Like:

export enum ProportionalLayout {
    Enabled,
    DisabledWhenViewMaximized,
    Disabled
}

export interface ISplitViewOptions<TLayoutContext = undefined> {
	/**
	 * Resize each view proportionally when resizing the SplitView.
	 *
	 * @defaultValue `true`
	 */
	readonly proportionalLayout?: boolean | ProportionalLayout;
}

That way, we can preserve a maximized view's state across layout() calls. We can even have tests for this. The problem is what happens when the user resizes the splitview until it reaches the sum of all minimum sizes: at that point no view will be maximized any more. So, growing the splitview from then on would make it grow all views proportionally. This is why using layout priorities would be benefitial here. But we can also live with that behavior.

As for #137865, the grid/splitview already supports sizing options when adding views. The EditorPart just mostly uses Sizing.Distribute, which causes today's behavior. I would first try to fix the issue by using a different sizing option here.

Thanks for all the details, @joaomoreno. I tried looking into it, but I'm not all the familiar with the code, so I didn't make it too far. I'll try to work on in over the next week. For both issues, I probably still need to add a function to determine if there is a maximized view first, right? For #70083, I'd need to check that if DisabledWhenViewMaximized is set. For #137865, I'd need to know that to know if I should set Sizing.Distribute or not.

For #70083, essentially, I would keep the following code, but only use it if DisabledWhenViewMaximized is set, right?

For #137865, what do you think of adding Sizing.Maximize and then adding code in doAddView to update the sizes?

Hm... After sleeping on it, I'm not entirely sure of my suggestions any more. Your initial PR might actually be a good option moving forward. 🙈

Let's do this: let's add test cases for the new splitview behavior you introduced in this PR. That will help us understand what it introduces and other bugs it might cause, such as unintentional resizing when a view is maximized. Remember that the splitview is used across the workbench in many cases, not just editor grids.

I added test for this. Noting mainly for myself that I can run them with these commands:

./scripts/test.sh --glob **/editorService.test.js
./scripts/test.sh --glob **/splitview.test.js

I wasn't positive if I put the test for #137865 in the right spot, so please let me know if I should move it.

I'm pretty new to VS Code and have gotten a grasp of some things enough to fix some things, but don't have a full understanding of the VS Code internal code structure. Is there any documentation I can read on that? In particular, I'm not really sure what the "workbench" vs "editor grid" vs "splitview" terms all mean?

@joaomoreno, do you need me to do anything else on this?

No need for anything else... just need to time to properly look into it. Sorry about that.

No problem. Thanks. Just wanted to be sure I didn't miss something.

I merged main and cleaned up the failing tests after that.

I'm very very sorry to only pick this up right now.

I've found the following issues:

• When a single group is open, opening a file on the side will now make that group maximized.
• When three views are open, one is minimzed and the rest of space split between the other two, the proportional resize will still stretch the minimized view.

While these issues could be fixed with the proposed approach, I went a different direction. I made proportionalLayout a property of each view. That way, the editor group views can claim not to be a part of the proportional layout algorithm, whenever they are minimized. This is simpler to maintain and understand than the original proposed change of this PR. This fixes #70083.

Additionally, I also made sure to maximize new groups if the reference group was maximized. This fixes #137865.

I'll push my changes on top of this PR so we still have you as a contributor, thanks so much for your patience and passion @ssigwart. 🍻

Thank you, @joaomoreno!