added Center Mode (#15684) #40757

SrTobi · 2017-12-23T15:45:35Z

As described in #15684 this adds editor centering for the zen mode. I added two options:

zenMode.centerEditor controls if the centering should be used
zenMode.centerEditorSize controls the size of the centered editor. you can either specify the size using a size string (e.g. "60%" or "600px") or you can specify the size of the two halfs of the editor (seen from the center)

"zenMode.centerEditorSize": {
  "left": "30%",
  "right": "100%"
}

With this the editor would occupy 30% of the left side of the window and 100% of the right side.

msftclas · 2017-12-23T15:45:46Z

All CLA requirements met.

SrTobi · 2017-12-23T16:05:29Z

It says that editorGroupsControl.ts is not formatted. But I don't know why (and it doesn't say why)... I had to commit it via git commit --no-verify because I couldn't figure this out... If I use the buildin vscode Format Code command it destroys the whole file... is there some script that does the formating?

[15:51:40] Using gulpfile ~/build/Microsoft/vscode/gulpfile.js
[15:51:40] Starting 'hygiene'...
/home/travis/build/Microsoft/vscode/src/vs/workbench/browser/parts/editor/editorGroupsControl.ts is not formatted
.....................................................
[15:53:27] 'hygiene' errored after 1.77 min
[15:53:27] Error: Hygiene failed with 1 errors. Check 'build/gulpfile.hygiene.js'.

edit: I fixed it... but only by nearly going line by line to find the formating problem... is there a better way? for next time

isidorn · 2017-12-28T18:51:57Z

@SrTobi thanks a lot for your PR. This functionality is needed and I really appreciated that you submited a PR. However it is usually best to first provide an empty PR where we can discuss on how to potentially solve this - just so you know for the future.

For now I did a quick review, and the issue that I see is that the layouting magic is happenig in the editorGroupsControl.ts I believe all the layouting math should be done in the WorkbenchLayout and the workbench layout should just pass the apropraite dimension to the editor part.
The issue with my proposal is that you only want this when you have one editor, so that is the argument to put it in the EditorsGroupControl since the WorkbenchLayout does not care about number of open editors.
However I also leave this up to @bpasero to comment since he owns the EditorsGroupControl

As for the settings and options they are fine overall, I would just polish them a bit, but let's first get the layouting correct.

SrTobi · 2017-12-29T04:31:27Z

@isidorn I was aware that the layouting happens in editorGroupsControl but I specifically wanted the tab bar taking the full space and not being centered as well (which would be the case if I had centered the whole editorGroupsControl). That's why I had to move it into editorGroupsControl. That was simply a design decision and could be done either way.

This becomes even more important with the new idea to also make the centered mode available in tho non-zen-mode (which we discussed in #15684). The settings we worked out there are more fitting for the use cases of most users, I think.

bpasero · 2018-01-03T13:35:17Z

src/vs/workbench/browser/parts/editor/editorGroupsControl.ts

@@ -86,6 +89,23 @@ export interface IEditorGroupsControl {
 	dispose(): void;
 }

+function toSize(sizeStr: string, maxSize: number, defaultSize: number): number {


@SrTobi Any reason why this method is not a private method within the EditorGroupsControl close to where it is being used?

bpasero · 2018-01-03T13:38:01Z

I think the approach is fine to have it inside EditorGroupsControl and it seems to work OK. However what is not clear to me and needs to be decided is a) under which condition this setting should apply and b) how the setting looks like.

a) from what other people seem to say they want to center the editor independently from zen mode and I think it is fine to allow this independent from it

b) some seem to want a setting of the size based on character count and not relative percentages. I also wonder if maybe as a user you should be able to resize the editor using sashes to the left and right to configure the right size without having to manually edit this in settings

mjbvz · 2018-01-06T00:21:06Z

src/vs/workbench/electron-browser/main.contribution.ts

+			'default': false,
+			'description': nls.localize('zenMode.centerEditor', "Controls if a single editor is centered when in zen mode.")
+		},
+		'zenMode.centerEditorSize': {


I'm in favor of a simpler approach where the max centered editor size is based on columns, as with editor.wordWrapColumn

SrTobi · 2018-01-11T15:37:58Z

@bpasero I like the idea with the sashes, but then the question when to activate the center mode becomes even harder, or not? Maybe combine both ideas:

The user defines a number N of characters
We calculate the width W of an EditorGroupsControl which holds exactly N characters in one line
If the available space is greater than W => activate the centered mode
Dependent on the user settings do not limit the editor size on the right side
Instead of using fixed borders add sashes left and right (right only if the user has deactivated 4.)

Then two questions remain:

Do we save the width adjusted by the user with the sashes, or not. And if we save it, does it have any effect on our decision when to activate the centered mode?
What do we do with multiple EditorGroups? Do we simply deactivate the centered mode (as the current PR does it) or do we center both of them?

And then one technical question:

How to calculate W in step 2. Does a function exists that does that? I mean it's not done with N * fontWidth because there might be line numbers and a scroll bar and stuff. We could, of course, ignore that when calculating W.

SrTobi · 2018-02-04T21:18:07Z

Ok, I changed the PR and streamlined the settings a lot.

The Center Mode is now independent from the zen mode.
It can be activated automatically or manually by the "Toggle Center Mode" action.
If active, it will set the width of the active silo to centerMode.size and center it.

The settings are now as follows:

centerMode.autoActivate has the options always, zen, fullscreen and never. It controls in which context the center mode should be activated automatically.
centerMode.size controls the size of the centered silo.
centerMode.adoptRight -> Normally, on the right side of the centered silo would be free space. With this option the silo can be expanded all the way to the right border
centerMode.onlyEditors -> I think most people would use the centered mode only for the text editor... it doesn't make much sense - in my opinion - to use it for a diff widget or a settings page or welcome page. But if you want that, you can set onlyEditors to false.

bpasero · 2018-02-07T17:28:02Z

@SrTobi I would try to reduce the settings to begin with and make this feature simple. For that I think its good that it is decoupled from zen mode now.

Settings to drop or question:

centerMode.adoptRight drop until there is demand for it (always show free space left and right)
centerMode.size we could allow an array here so that a user that wants the centerMode.adoptRight functionality could provide the size to the left and right (e.g. [1200, 0])
centerMode.onlyEditors drop and only enable for text editors
centerMode.autoActivate this one is confusing to me, what does always or never really mean? If I compare this with zen mode, there we just have one setting: zenMode.fullScreen and I can understand that.

isidorn · 2018-02-07T19:47:34Z

@SrTobi great work.
Mostly agree with @bpasero
Too much settings to start. It is good that it is decoupled from zenMode

Definetely remove centerMode.adoptRight, centerMode.onlyEditors
I would also remove centerMode.autoActivate and let's start with this being a command. Also the zen mode by default will enter this mode. On top of that zenMode can have a setting if it should transition to this mode or not.
Sorry if I missed this discussion but why are we not having 2 sashes so the user can control the horizontal size instead of the centerMode.size settings
Name centerMode sounds a bit ugly since I would not call this a mode, sounds like it could clash with zenMode which is not correct
Does the centerMode stay active if the user opens 2 editors side by side. IMHO we should consider if the centering should take place only if one editor is open and we automatically escape it if 2 or more editor groups exist. I think this is worth considering as it might behave nice for the most common use case. User has one editor, centers the thing. As soon as he does side by side we exit the center mode, but we return to it if the user closes the editors on the side.
I prefer "Toggle centered layout" to "Toggle center mode". But we can polish the names once we agree on functionality

Edit: now I see some ideas on automatic triggering based on width. Imho this is too complex for users and should behave based on number of open editor groups.

SrTobi · 2018-02-08T10:22:58Z

@bpasero The idea behind autoActivate was that the user might want to always enter centered mode if he uses fullscreen and/or zenmode but not when in the normal view. That's what I need the centered mode for 😄 And that's why the first version of the PR only activates it in zen mode. never and always mean exactly that: The centered mode is always (independent of fullscreen and zen mode) forced by the settings or never respectively. Independent of the settings the centered mode can than be activated by the user using the "Toggle center mode" action.

@isidorn The moment a second silo is opened, the centering is prevented. So no centering, but no settings or internal state changes either. That means, if one of the two silos is closed, the remaining silo will be centered again.

To centerMode.onlyEditors: yeah that can be removed.
To centerMode.autoActivate: I think we can scrap that, but then we should add an option to zen mode which activates the centered mode
To the naming: I like the idea renaming it from centered mode to centered layout.
To adoptRight: I think this is a really cool feature. If I center my editor, I want to do it because I want to look at the center of my screen. That is achieved by a left margin because at least 90% of the code are in the first 90-120 columns. With a margin on the right side, the remaining 10% of the code are now either wrapped to the next line or hidden accompanied by a horizontal scroll bar. And that despite of the fact that there is a big free space on the right side of my editor. That's why I think having only a left margin would be quite cool.
To adoptRight/size: @bpasero The interval thing was what the first version of this PR did and I think many people criticized it for beeing too complicated and I think so now as well (even I can not easily see what you mean by [1200, 0] 😆).
I still like the idea with the sashes which would also mean that we can really scrap all settings for the centered layout, except the auto center in zen mode (which would of course wander into the zen mode settings) and it is more user friendly as well.

When we use sashes, then there are two more questions:

What do we do, when the user moves the sashes all the way to the border? Especially on the left side where the sidebar is. I don't think it's a good idea to have to sashes next to each other without space in between.
We could either prevent that and enforce a minimal margin of e.g. 8px or we deactivate the centered layout the moment the user drops the sash at the border (then we should also inform the user that the centered layout has been deactivated).
Do the two sashes work independently or are they coupled (meaning that when the left sash is moved to the left, the right one moves automatically to the right in order to keep the editor centered). The first one is clearly more flexible but also kind of destroys the idea of centering the editor. The user would now have to do the centering himself which is very hard to nearly impossible to get it right pixel-precise.

What do you think? Otherwise I would start implementing the following changes sometime in the next days:

Remove all the settings and add the one for the zenmode
Add sashes that are coupled and deactivate the center layout if they are moved all the way to the border.

isidorn · 2018-02-08T10:46:13Z

@SrTobi thanks for your comments.

yes I can add an option for zenMode to automatically go into this. But let's try to keep this PR minimal and add things on top of it later on. This setting will be on by default.
Let's work on the naming once we have done the functionality. But yeah getting rid of "mode" sounds good
adoptRight might be a cool feature, but as already mentioned let's keep this PR minimal and add things on top. Once we have the basic funcionality we can debate more easily about what is still missing in seperate PRs. So I would prefer if we do not do it yet
Now I was pondering about the coupling ant to me it seems like this is really tied with the auto hide behavior. After some pondering I think we can only auto hide if they are coupled. The downside of them being coupled is that if the user has the sidebar opened and wants his editor to be in the exact center of the monitor he can not really do that. So for me it seems like we have two options:

Couple sashes, auto hide on 95% (like panel height min - panel is the area with the terminal)
Indipendent sashes, limit theirs size to 95% (like panel height max). We can only limit the one on the sidebar side.

Since we already auto exit this mode when more than 1 editor is open I would vote for option 2. To give more flexibility to those huge montiors and to let the users have their editor really centerd when explorer is open. Also with this adoptRight is not needed and we get rid of complex settings.

Feature which we will add on top when the users complain about pixel perfection. Double click on sash brings them both into default position (we have this in other pars of our ux), double click again takes 2/3 of the width, double click again 3/4 double click again the default.

Let's see what @bpasero thinks before you start the implementation.
Bottom line I do not think we need any settings in this PR. Which makes naming easier.

SrTobi · 2018-02-08T12:18:01Z

Yeah that sounds good, though I would also add double clicking on a sash and then dragging brings it into the coupled mode... so we can have all the features :D and it would be somewhat natural (may I add that that is exactly what my usecase would be). And don't tell me about hidden features... I didn't knew about the double clicking until you mentioned it 😄 (good to know by the way 👍)

SrTobi · 2018-02-08T12:19:41Z

src/vs/workbench/browser/parts/editor/editorGroupsControl.ts

+
+			if (tryCentering) {
+				const size = Math.max(100, this.configurationService.getValue<number>('centerMode.size'));
+				const adoptRight = this.configurationService.getValue<string>('centerMode.adoptRight');


This line should be getValue<boolean>

SrTobi · 2018-02-08T12:25:49Z

src/vs/workbench/browser/parts/editor/editorGroupsControl.ts

+				const centerOnlyEditors = this.configurationService.getValue<string>('centerMode.onlyEditors');
+				const availableWidth = this.dimension.width;
+
+				const isTextEditor = editor instanceof TextResourceEditor;


instanceof is not a good design... in fact it doesn't even work correct. Markdown editors and normal text editors seem to be of class type TextFileEditor (which I was not able to import because linter import rules).
Best option is to add another abstract method like allowsCentering(): boolean or something to BaseEditor and let the implementation decide whether it itself should be centered or not

bpasero · 2018-02-08T17:48:04Z

I like the idea of replacing the now complicated centerMode.autoActivate with something like zenMode.centerEditor because the zen related settings already go into that direction where you can tweak these things.

Avoiding the remaining settings and having 2 sashes left and right to the editor seems like a good thing to play around with: not sure about the coupling to be honest (we do not have that anywhere else in our UI). Maybe we could say that Ctrl+click moves both or double click does something special but imho we can also look at that later. We could also introduce 2 more sashes top and bottom of the editor so that people could size the editor area anyway they want (some people seem to want a margin to the top of the editor).

Bottom line is that we should have some good defaults out of the box that make the "centered editor" mode useful without configuration. I would probably expect that default to work in any resolution (e.g. not hardcoded to a specific number but relative to the window size). E.g. with the current 1200 value I was not even seeing the editor centering when I was working on my normal laptop screen and thought the feature was broken.

Last, we need to figure out where to store the user configured sash positions. I guess it would make sense to store this via storage service in the GLOBAL scope and not workspace so that the user can tweak it once and have it in all workspaces?

iCodeForBananas · 2018-02-08T17:57:52Z

@bpasero @SrTobi Just throwing this out there, but Sublime Text uses the longest line as the width to auto center the code so it expands as the length gets longer or shrink as it gets shorter. Thus working no matter what file you're looking at.

SrTobi · 2018-02-08T21:28:50Z

@bpasero yeah, I think GLOBAL scope is fine.

@bpasero you're right: defaults are important. If the user activates the centered layout, he must be able to see the effect immediately.
A width depending on the window size seams reasonable. I really liked the idea of @michaeljcalkins, so I tested it with subl3 and some vscode .ts files (the feature had to be activated first because line wrapping was activated and sublime kept the editor size at 80 chars) and I found it not quite satisfying. As I mentioned above long lines are not a good indicator for where the bulk of code is - column wise. One would have to calculate some "mass of text" value and align according to this value. And though I find that's very interesting, it's out of scope for this PR and I think it conflicts somewhat with the sashes idea.

Another problem with the sashes: are they proportional or absolute? That's very important when changing the window size. I think most reasonable would be to make the size of the editor (between the two sashes) absolute — so the editor size doesn't change on resize — and let the left/right margin grow/shrink proportional. That would also provide a smooth transition to the non centered layout when shrinking the window too much. In the store we would have to save the size of the editor in pixels and the proportion of the right/left margin.

On the other Hand, it does create problems with any default size which depends on the window size because different windows sizes — when the centered layout is initially activated — would yield different permanently saved editor sizes. Though I think the feature would mostly be used in zen mode and so I think it's somewhat reasonable to ignore the former mentioned problem and just set it to 50% of the window size (after zen mode is activated). After all the most important point in the default size is that the user recognizes the feature and is able to modify the size with the sashes himself.

isidorn · 2018-02-09T11:05:45Z

Seems like @bpasero and me are in agreement and you have something to start with. Top and bottom sashes are step2, so not for now.
As for where to store the setting, storageScope.GLOBAL seems like a good place, since you configure this per your Monitor, not per your workspace.

@SrTobi as for the propritaonal vs absolute, the sashes are absolute and they will not change when the window resizes. And that is fine for this PR.
After we merge in the PR we can add aditional events to listen on window resize and react appropriatly if we want to improve this.
Apart from that, you choose what you want to store in the storage. So you can also store a proportion, so when getting data from storage you restore the sashes propritonaly and not absolutely.

@michaeljcalkins thanks for the suggestion, we can add that nice feature later.

Bottom line, let's try to get the basic funcionality in and not worry about fancy features on top. We will nicely polish this once we have the inital pr in.

Thanks a lot

SrTobi · 2018-02-20T01:38:53Z

Ok, I fixed your suggestions and added the storing of the position and the location.

Things left to do:

The instanceOf suggestion
drawing the sashes. I don't know what to do here... Maybe simply add a border right and left via css?

bpasero · 2018-02-20T06:26:33Z

@SrTobi there seem to be warnings in the toggle action. And then, when I try this out and select the center mode from the menu, the editor does not change, is that a bug?

isidorn · 2018-02-20T09:14:47Z

src/vs/workbench/browser/parts/editor/editorGroupsControl.ts

 /**
 * Helper class to manage multiple side by side editors for the editor part.
 */
 export class EditorGroupsControl extends Themable implements IEditorGroupsControl, IVerticalSashLayoutProvider, IHorizontalSashLayoutProvider {

+	private static readonly CENTERED_LAYOUT_DATA_STORAGE_KEY = 'centeredLayoutData';


I would prefix the value of this key with 'workbench' to be aligned with similar storage keys

isidorn · 2018-02-20T09:16:40Z

src/vs/workbench/browser/parts/editor/editorGroupsControl.ts

@@ -969,6 +1015,31 @@ export class EditorGroupsControl extends Themable implements IEditorGroupsContro
 		// Silo Three
 		this.silos[Position.THREE] = $(this.parent).div({ class: 'one-editor-silo editor-three' });

+		// Center Layout stuff


Minor. Feels like code duplication, we do the creation and listeners twice. Can't we have a helper method that just takes a centered sash and nicely initilizes it. For that the DragStart and Drag methods would have to take sashes as parameters and based on Sash do different things.
Which might not be too bad, currently I feel like there are too many methods.

I don't think that's a good idea... that would make the individual method body larger... and break the coding style for sashes... I mean the class is pretty big but that would require an additional PR that really breaks the class apart. I think it's much more clean the way it is... what we could do is outfactor the initialization for the sashes. I did that in this commit SrTobi-Forks@abccb77 (it's not part of this PR at the moment) but I am not really sure if that makes the code more structured (in fact, it adds one more method 😄 ).

Ok, makes sense

isidorn · 2018-02-20T09:17:43Z

src/vs/workbench/browser/parts/editor/editorGroupsControl.ts

+		this.setCenteredEditorPositionAndSize(size < this.minSize ? pos + (size - this.minSize) : pos, size);
+	}
+
+	private saveCenterdLayoutData(): void {


I would probably call this storeCenteredLayoutData

isidorn · 2018-02-20T09:18:14Z

src/vs/workbench/browser/parts/editor/editorGroupsControl.ts

+			this.layoutVertically &&
+			this.editorGroupService.getStacksModel().groups.length === 1 &&
+			this.partService.isLayoutCentered() &&
+			this.visibleEditors[Position.ONE] instanceof TextResourceEditor;


Yeah definetely remove this instanceof check, since the feature does not behave like it should with it. @bpasero was unable to try it out.

isidorn · 2018-02-20T09:20:12Z

@SrTobi great, I added a bit more comments. @bpasero will also review that file later today I believe.
As for the css borders, you can experiment with the border if you like it we can take it. An alternative is to use a different color of the left and right margin of the editor (some viewlet color perhaps). The idea is to make it look like a background.
Also you do not have to worry about this sash color, I can also take care of it after we merge the PR.

Thanks a lot for your great work!

SrTobi · 2018-02-20T11:34:36Z

@isidorn I fixed your remarks. I still think we should have something that prevents the diff editor from being centered... it really needs all the space it can get

I played a little bit around with the border for the sashes but I'm not sure on how to do it correctly... I think I would prefer a thin one pixel border with the same color the scrollbar border has (#383838 for the normal dark+ theme).

Here is a screenshot:

I added a commit for this but it seems somewhat messy (on the other hand: it is css 😄 ). Maybe you could enhance that further. With my solution, there also seems to be a gap between the actual scrollbar (not only the container) and the right border (it's not visible on the screenshot because the scrollbar is hidden).

isidorn · 2018-02-20T11:46:26Z

@SrTobi great for addressing everything. That last commit is a total mess so I suggest to revert it 😊
The issue here is that we also have to take the theming story into account.
However the screenshot shows that this solution is not that bad. I can take care of this, you can just revert the last commit.

So when that is reverted all is good from my side, let's just wait for @bpasero before merging

As for the DiffEditor, same as when 2 groups get opened we should get out of CeneterdMode temporarly while a DiffEditor is open, however we have a helper function to check if something is a DiffEditor. You would also have to react on editors being opened if you are not already. If you feel like it give this a try, if not I can also cover it once we merge.

This reverts commit caf6e5e.

SrTobi · 2018-02-20T14:34:56Z

@isidorn ok, I reverted the commit :D
I am not sure what you mean by "react on editors being opened" or at least I'm not sure what the problem should be. I think it's best if you take over from here. I tried to use the isDiffEditor but wasn't able to find the correct object to give as argument. I think it's easier for you, because you know the internal editor structure better than I do 😄

When this is merged I would maybe work on the auto activation of the centered layout in zen mode. That's a feature that I would like to see very much.

isidorn · 2018-02-20T15:43:13Z

@SrTobi sounds great. Let's wait for the merge and once that is done you can look into zen mode setting which should not be complicated.

SrTobi · 2018-02-20T15:49:18Z

@isidorn ok, let's do it that way

bpasero · 2018-02-21T06:37:09Z

LGTM, I moved the sashes into the editor container instead of the parent because I think they belong there.

isidorn · 2018-02-21T08:57:04Z

@bpasero awesome, thanks for merging this in.
@SrTobi do you want to create a new PR adding setting zenMode.centeredLayout and I take care of the other polish?

Code pointers
https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/electron-browser/main.contribution.ts#L425
https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/electron-browser/workbench.ts#L118

SrTobi · 2018-02-21T09:39:09Z

@bpasero good idea! looks great
@isidorn ok. I'll open the PR later today.

isidorn · 2018-02-21T10:34:18Z

@SrTobi I have pushed the border color and not to go into center mode for diff editors.
Once we have a zenMode setting we will be in a good spot.
I will present this today at our meeting to get feedback, and next week we have endgame testing so I will create a test plan item to cover this feature so we test it well.

Apart from zenMode setting I would not add any other features on top until we get some user feedback.

isidorn · 2018-02-21T14:19:36Z

@SrTobi the presentation in the meeting went great. Only one suggestion came: by default the sashes should be paired, but the user can press alt to unpair them whilce clicking and only control one sash. I will implement this now, since I think it is a great idea.

SrTobi · 2018-02-21T14:53:12Z

@isidorn good idea. I really like that 👍

dodheim · 2018-03-08T07:28:49Z

Of the three languages I use VSCode for, only one of them enters center mode properly. I want to open an issue, but I'm not sure where – is this a VSCode problem, or a problem with respective extensions the two languages that aren't working for me? (F# is working, C++ and Rust aren't.)

I know this question is very light on details, but I'm not sure what information would be helpful, or whether I'm posting in the right place...

isidorn · 2018-03-08T08:42:47Z

@dodheim open a new issue with exact reproducable steps and we can investigate further. Thanks

SrTobi force-pushed the master branch from acd6857 to fd709fe Compare December 23, 2017 17:30

weinand assigned isidorn Dec 23, 2017

bpasero self-assigned this Dec 28, 2017

bpasero added this to the On Deck milestone Dec 28, 2017

SrTobi force-pushed the master branch from fd709fe to ae17388 Compare December 30, 2017 10:35

bpasero reviewed Jan 3, 2018

View reviewed changes

mjbvz reviewed Jan 6, 2018

View reviewed changes

SrTobi force-pushed the master branch from ae17388 to 8f41147 Compare February 4, 2018 20:59

SrTobi changed the title ~~added editor centering for zen mode (#15684)~~ added Center Mode (#15684) Feb 4, 2018

isidorn removed their assignment Feb 5, 2018

SrTobi commented Feb 8, 2018

View reviewed changes

bpasero modified the milestones: On Deck, February 2018 Feb 8, 2018

fixed import warnings for toggle centered layout actio

ac710ad

isidorn reviewed Feb 20, 2018

View reviewed changes

SrTobi added 5 commits February 20, 2018 10:44

aligned centered layout data storage key with the one from workbench

4e2f3bd

renamed saveCenteredLayoutData -> storeCenteredLayoutData

d1a5230

removed instanceof-check for non normal editor widgets

a403a53

removed TextResourceEditor import

3e131cc

added a 1px border to indicate the sashes

caf6e5e

Revert "added a 1px border to indicate the sashes"

cdd2bde

This reverts commit caf6e5e.

💄

a0da58b

bpasero merged commit 094f5ee into microsoft:master Feb 21, 2018

SrTobi mentioned this pull request Feb 21, 2018

Setting to center the layout when turning on the zen mode #44116

Merged

isidorn mentioned this pull request Feb 21, 2018

Zen mode: Centered Editor Layout #15684

Closed

akbyrd mentioned this pull request Mar 7, 2018

Share ux state across machines #45242

Closed

github-actions bot locked and limited conversation to collaborators Mar 27, 2020

added Center Mode (#15684) #40757

added Center Mode (#15684) #40757

Conversation

SrTobi commented Dec 23, 2017

msftclas commented Dec 23, 2017 • edited Loading

SrTobi commented Dec 23, 2017 • edited Loading

isidorn commented Dec 28, 2017 • edited Loading

SrTobi commented Dec 29, 2017

bpasero Jan 3, 2018 • edited Loading

Choose a reason for hiding this comment

bpasero commented Jan 3, 2018

Choose a reason for hiding this comment

SrTobi commented Jan 11, 2018

SrTobi commented Feb 4, 2018 • edited Loading

bpasero commented Feb 7, 2018 • edited Loading

isidorn commented Feb 7, 2018 • edited Loading

SrTobi commented Feb 8, 2018

isidorn commented Feb 8, 2018 • edited Loading

SrTobi commented Feb 8, 2018

SrTobi Feb 8, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bpasero commented Feb 8, 2018

iCodeForBananas commented Feb 8, 2018

SrTobi commented Feb 8, 2018

isidorn commented Feb 9, 2018 • edited Loading

SrTobi commented Feb 20, 2018

bpasero commented Feb 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

isidorn commented Feb 20, 2018 • edited Loading

SrTobi commented Feb 20, 2018

isidorn commented Feb 20, 2018

SrTobi commented Feb 20, 2018

isidorn commented Feb 20, 2018

SrTobi commented Feb 20, 2018

bpasero commented Feb 21, 2018

isidorn commented Feb 21, 2018

SrTobi commented Feb 21, 2018

isidorn commented Feb 21, 2018

isidorn commented Feb 21, 2018

SrTobi commented Feb 21, 2018

dodheim commented Mar 8, 2018

isidorn commented Mar 8, 2018

msftclas commented Dec 23, 2017 •

edited

Loading

SrTobi commented Dec 23, 2017 •

edited

Loading

isidorn commented Dec 28, 2017 •

edited

Loading

bpasero Jan 3, 2018 •

edited

Loading

SrTobi commented Feb 4, 2018 •

edited

Loading

bpasero commented Feb 7, 2018 •

edited

Loading

isidorn commented Feb 7, 2018 •

edited

Loading

isidorn commented Feb 8, 2018 •

edited

Loading

SrTobi Feb 8, 2018 •

edited

Loading

isidorn commented Feb 9, 2018 •

edited

Loading

isidorn commented Feb 20, 2018 •

edited

Loading