Conversation
|
@bpasero I managed to get empty workspaces working, it's just super rough. I'd love some feedback on the general approach and position of things, specifically:
I'll be polishing this tomorrow and will probably stay up so we can get this in before the weekend. |
src/vs/code/electron-main/window.ts
Outdated
| extensionDevelopmentPath?: string; | ||
| allowFullscreen?: boolean; | ||
| titleBarStyle?: 'native' | 'custom'; | ||
| vscodeWindowId?: string; |
There was a problem hiding this comment.
@Tyriar I would suggest to call this id and instead fix all users of the current id property to use vscodeWindows.win.id because that makes it very clear what ID is being asked.
src/vs/code/electron-main/windows.ts
Outdated
| // TODO: There's an extra empty workspace opening when restoring an empty workspace (sometimes) | ||
| emptyToRestore.forEach(vscodeWindowId => { | ||
| const configuration = this.toConfiguration(openConfig); | ||
| configuration.vscodeWindowId = vscodeWindowId; |
There was a problem hiding this comment.
@Tyriar why is this done here and not inside the toConfiguration method?
src/vs/code/electron-main/windows.ts
Outdated
| configuration.vscodeWindowId = vscodeWindow.vscodeWindowId; | ||
| if (!configuration.extensionDevelopmentPath) { | ||
| // TODO: Cover closing a folder/existing window case | ||
| this.backupService.pushEmptyWorkspaceBackupWindowIdSync(configuration.vscodeWindowId); |
There was a problem hiding this comment.
@Tyriar I suggest to move this up to the place where we already call pushWorkspaceBackupPathsSync so that we have it in one place. doing this from toConfiguration is very weird. As a caller of this method I would expect to get a configuration object but as a side effect I am writing to the backup folder??
| pushWorkspaceBackupPathsSync(workspaces: Uri[]): void; | ||
|
|
||
| // TODO: Doc | ||
| pushEmptyWorkspaceBackupWindowIdSync(vscodeWindowId: string): void; |
There was a problem hiding this comment.
@Tyriar maybe merge both methods into one and the return type can either be a path to a workspace or a window id? might make the naming easier.
|
|
||
| execPath: string; | ||
| appRoot: string; | ||
| vscodeWindowId: string; |
There was a problem hiding this comment.
@Tyriar we cannot really add this here because environment service is agnostic to windows, we have one in the shared process as well as the CLI. I suggest to put this into the IWindowService on the renderer side.
|
@Tyriar do we actually need to come up with and pass around a window id only to know from where to restore backups? Why not let the backup service deal with it:
Just a thought... |
| // Backup File Service | ||
| const workspace = this.contextService.getWorkspace(); | ||
| serviceCollection.set(IBackupFileService, this.instantiationService.createInstance(BackupFileService, workspace ? workspace.resource : null)); | ||
| serviceCollection.set(IBackupFileService, this.instantiationService.createInstance(BackupFileService, this.windowService.getCurrentWindowId())); |
src/vs/code/electron-main/windows.ts
Outdated
| if (emptyToRestore.length > 0) { | ||
| emptyToRestore.forEach(backupFolder => { | ||
| const configuration = this.toConfiguration(openConfig, null, null, null, null, backupFolder); | ||
| const browserWindow = this.openInBrowserWindow(configuration, openInNewWindow, openInNewWindow ? void 0 : openConfig.windowToUse); |
There was a problem hiding this comment.
@Tyriar we always want each of these windows to open inside a new window so I suggest to just call
const browserWindow = this.openInBrowserWindow(configuration, true /* new window */);
In the same way as we do for restoring folders.
src/vs/code/electron-main/windows.ts
Outdated
| } | ||
| } | ||
|
|
||
| this.backupService.registerWindowForBackups(vscodeWindow.id, !configuration.workspacePath, configuration.backupFolder, configuration.workspacePath); |
There was a problem hiding this comment.
@Tyriar are you missing the check for openConfig.cli.extensionDevelopmentPath on purpose here?
There was a problem hiding this comment.
Yes, moved it to registerWindowForBackups so it was handled by the BackupMainService. Now that you mentioned it though, that was there for a good reason, thanks for pointing that out 👍
src/vs/code/electron-main/window.ts
Outdated
| perfWindowLoadTime?: number; | ||
|
|
||
| workspacePath?: string; | ||
| backupFolder?: string; |
src/vs/code/electron-main/windows.ts
Outdated
| if (emptyToOpen.length > 0) { | ||
| if (emptyToRestore.length > 0) { | ||
| emptyToRestore.forEach(backupFolder => { | ||
| const configuration = this.toConfiguration(openConfig, null, null, null, null, backupFolder); |
There was a problem hiding this comment.
@Tyriar something is weird about backupFolder. As someone that tries to understand the code I would assume every window has an associated backupFolder. but that is not true, only the empty windows to restore have it. I would make this more obvious. Maybe remove the property from IWindowConfiguration and just pass it into openInBrowserWindow method? Also needs a clearer name to make its meaning more obvious.
src/vs/code/electron-main/windows.ts
Outdated
| emptyToRestore.forEach(emptyWorkspaceBackupFolder => { | ||
| const configuration = this.toConfiguration(openConfig, null, null, null, null); | ||
| const browserWindow = this.openInBrowserWindow(configuration, openInNewWindow, openInNewWindow ? void 0 : openConfig.windowToUse, emptyWorkspaceBackupFolder); | ||
| const browserWindow = this.openInBrowserWindow(configuration, true /* new window */, openInNewWindow ? void 0 : openConfig.windowToUse, emptyWorkspaceBackupFolder); |
There was a problem hiding this comment.
@Tyriar I would not assume we have a windowToUse in this case ever?
| @@ -51,11 +51,6 @@ export class BackupMainService implements IBackupMainService { | |||
| } | |||
|
|
|||
| public registerWindowForBackups(windowId: number, isEmptyWorkspace: boolean, backupFolder?: string, workspacePath?: string): void { | |||
There was a problem hiding this comment.
@Tyriar I didnt know you had this check in here, I am also fine leaving it there to keep this knowledge inside the service!
There was a problem hiding this comment.
That was my thinking, didn't we want to keep that check outside though due to the config in IEnvironmentService potentially being stale or something?
There was a problem hiding this comment.
Hm yeah maybe. We can leave it there for now. The problem is that the main side only ever has one environment service and so a second window would not answer this check correctly.
Just in case
Fixes #13733