-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'New Window' Command #9519
Add 'New Window' Command #9519
Conversation
68d1e0e
to
16bbc48
Compare
16bbc48
to
5d0295e
Compare
/** | ||
* The window hash value that is used to spawn a new default window. | ||
*/ | ||
export const DEFAULT_WINDOW_HASH: string = '#!empty'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have mixed feelings about using this to solve the problem of opening without reloading the workspace.
Positive feelings:
Opening a new window does feel like the sort of thing that a
WindowService
ought to do, so locating that functionality in thecore
package makes sense.
Less positive feelings:
Knowing that the window hash represents the workspace maybe isn't a detail that
core
should know about, but a detail leaking out of theworkspace
package, which is clear given that the only function of this value is to stop the workspace service from doing what it would normally do. The workspace already has its own solution to this problem:
theia/packages/workspace/src/browser/workspace-service.ts
Lines 436 to 445 in 011f76e
/** | |
* Clears current workspace root. | |
*/ | |
async close(): Promise<void> { | |
this._workspace = undefined; | |
this._roots.length = 0; | |
await this.server.setMostRecentlyUsedWorkspace(''); | |
this.reloadWindow(); | |
} |
So I'm not sure exactly which way is best, but I'd prefer to see one solution to the problem of not loading a workspace rather than two.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi collin, do you have some ideas to implement this by using the WorkspaceService ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in the end my complaint has more to do with misgivings about how we treat the URL bar (that we don't react to changes unless the user does a hard refresh, for example) than it does with your solution. In reality, core
definitely does know what the hash is for (e.g. ElectronMainApplication.prototype.openWindowWithWorkspace()
sure knows), so using a specific hash for an empty workspace isn't a problem.
Maybe change the close
function in the workspace service to use the empty workspace fragment rather than using setMostRecentlyUsedWorkspace
dishonestly, and I'll be thoroughly satisfied 🙂. Sorry for the detour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to bother you again, but when you say the empty workspace fragment do you mean the DEFAULT_WINDOW_HASH ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, indeed, exactly. Sorry for the confusion in terminology. Mixing your HASH
term and the withFragment
method on URI's.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that I misunderstood something about what I have to change to the close method. For me, it is only used to clear the root by setting the most recent workspace uri to an empty string. Also, we use the empty hash value only to know when we are opening a default window and we are modifying the uri just after checking that condition with an empty string like it is shown in this picture :
If we modify the uri fragment with the hash value and let it like this, the root won't be clear anymore and a default window will not appear when we close the workspace.
registerKeybindings(registry: KeybindingRegistry): void { | ||
registry.registerKeybindings({ | ||
command: WindowCommands.NEW_WINDOW.id, | ||
keybinding: this.isElectron() ? 'ctrlcmd+shift+n' : 'ctrlcmd+alt+n' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually (but not always) when we do alternate sequences for browser and Electron, it involves replacing ctrlcmd
with alt
, so ctrlcmd+shift+n
-> alt+shift+n
. Is there a reason not to do that here?
This is working pretty well for me. Just some minor comments on the code. |
5d0295e
to
3822488
Compare
Please bring this up to date with master and fix existing conflicts, and it should be good to go. If you'd like to make the change to the |
@OmarSdt-EC Are you still working on this? It looks good to me as well, I think the |
@msujew Yes, I'm still working on it. I will rebase it and fix the conflicts thank you ! |
3822488
to
e5e156a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, Code LGTM and everything works well 👍
e5e156a
to
1f103bc
Compare
The following commit adds support for the 'New Window' command for both electron and browser targets. Also, it prevents a new electron or browser window to be spawned with a workspace. It includes : - The registration of the keybindings used in each target. - The registration of the command in the different menus of each target.
1f103bc
to
c0be505
Compare
electronWindow.loadURL(uri.toString(true)); | ||
async openDefaultWindow(): Promise<BrowserWindow> { | ||
const [uri, electronWindow] = await Promise.all([this.createWindowUri(), this.createWindow()]); | ||
electronWindow.loadURL(uri.withFragment(DEFAULT_WINDOW_HASH).toString(true)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change means that we will not restore the previous workspace if we do the following:
- start the
example-electron
application - open a workspace folder
- close the application
- re-start the application - the previous workspace is not restored and instead we fallback to the default state (without a workspace).
The following commit adds support for the 'New Window' command for both electron and browser targets. Also, it prevents a new electron or browser window to be spawned with a workspace. It includes : - The registration of the keybindings used in each target. - The registration of the command in the different menus of each target.
The following commit adds support for the 'New Window' command for both electron and browser targets. Also, it prevents a new electron or browser window to be spawned with a workspace. It includes : - The registration of the keybindings used in each target. - The registration of the command in the different menus of each target.
What it does
Fixes: #9391
The pull-request adds the
new window
command for both the electron and browser targets along with an appropriate keybinding and menu item (file menu). The command is used to spawn a new application window without a workspace.How to test
Review checklist
Reminder for reviewers