Vscode: Move panel.location from settings into local storage

[mjbvz]

Testing #36571

Repo steps

1. In a multiroot workspace
2. In your user settings have: "workbench.panel.location": "bottom"
3. In the workspace settings have "workbench.panel.location": "right"
4. The panel should appear to the right.
5. Now try using commands or the panel button to change the panel position to the bottom

Bug
Position cannot be changed

[isidorn]

@mjbvz this is expected behavior. Though I understand it is an ugly user experience.
You can have the same for many other things in our UX e.g status bar hidden, sidebar location and absolutely all the ux settings.

@sandy081 @bpasero why do we allow these settings to be written in the workspace settings in the first place. They should only be user settings. Do we already have an issue for that so I close this as a duplicate.
Bottom line: workspace settings should be only the ones which are allowed as resource settings.

Other suggestions on how to improve this are welcome

[sandy081]

IMO we are already too late to take such decision and this will be a breaking change.

One suggestion here is let the commands update the value at the right place instead of hard coding to user settings. You can do that by not providing any target while writing using IConfigurationService.updateValue and the service writes it smartly.

[bpasero]

@sandy081 @bpasero why do we allow these settings to be written in the workspace settings in the first place. They should only be user settings. Do we already have an issue for that so I close this as a duplicate.
Bottom line: workspace settings should be only the ones which are allowed as resource settings.

I do not understand that statement. We have workspace settings since day 1 and the panel position is not a resource setting. It is perfectly fine that a user configures the panel in one workspace to be vertical and horizontal in the other, no?

[isidorn]

@sandy081 thanks for the suggestion. So this would write it to the most specific location? We should then change all our UX write settings to use this. @bpasero do you object if I change this for statusbar, sidebar and others

Sure it is perfectly fine but I personally do not buy that use case since day one :) I do not think users use workspace settings as a UX persistance mechanism.

[sandy081]

@isidorn Yes, there is a plan to adopt to all such settings. Please go ahead and adopt them. 👍

[octref]

StatusBar and Sidebar are different use cases than Vertical Panels.
I have global setting for StatusBar and Sidebar and don't foresee myself changing them ever (or have workspace setting for them). But for vertical panel, it's really when I move a window to a widescreen monitor I wish I could toggle the layout specific for that window using either a Quick Command or the Button on the Panel.

[Tyriar]

But for vertical panel, it's really when I move a window to a widescreen monitor I wish I could toggle the layout specific for that window

@octref makes a really good point, a user with a vertical and a horizontal monitor will be one of the common cases for wanting differing settings. Setting ti at a workspace settings level is clunky as you don't want to check this setting in.

Why don't we use the setting as the default, but when it's set by the user it's saved in the workspace's local storage? Perhaps there should be 2 sets of commands to compliment this as well, one to change the default and one to change the current window.

[bpasero]

Yeah, the panel location might be one of those where it is hard to decide if it should be a setting or a local storage thing. For example, we also put the sidebar visibility into local storage but not into settings because we think it changes often.

[sandy081]

One advantage of making something available as a setting is that you can copy and synchronise your set up across machines, for example, using Settings Sync Extension. In that perspective, panel location as a setting is good.

But for vertical panel, it's really when I move a window to a widescreen monitor I wish I could toggle the layout specific for that window

I see this is asking for supporting non-sharable workspace settings, for now we are advocating to use new Workspace as a workaround solution. If you do not want to pollute your settings under vscode\settings.json with your personal ones, you can create a workspace out of it and have your personal workspace settings in it. BUT, It has the limitation of restricting this solution only to folder workspaces.

[bpasero]

Yeah, but I think for a user this is not discoverable after all because you invoke the action and it changes the panel in all windows. I think that users would not even be aware of this thing being written to settings.

[sandy081]

True, but as a setting it gives advantage to those users who want to retain their set ups.

[isidorn]

After trying this out and processing user feedback I have decided to write the panel position into workspace storage and to deprecate the setting.
Users switch this all the time, and it just does not feel like a real setting as already nicely explaind in comments above.

I have decided to leave the other ux settings untouched since it seems that every setting based on the feeling either needs to go to local storage or to our settings.
Though I would argue that most of them should just go to local storage, but that is for another discussion.

[sandy081]

@isidorn Good. Would like to know what is our solution if users wants to have vertical panel as default?

[isidorn]

@sandy081 not supported since the downside is that they need to click one button per workspace

[bpasero]

How about seeding the default value actually from settings? I would maybe then also rename the setting to make clear that it would be the default value. We could apply this pattern also to the side bar visibility thing so that users can define a default initial state until the state is changed.

[isidorn]

@bpasero this sounds like it would align nice. However I am not convinced this would actually be used by people.
Waiting for a user feature request / complain before I actually jump on this.
Not a fan of just adding settings for everything.