Fixes #4803: Adding support for swipe gestures on macOS.#23663
Fixes #4803: Adding support for swipe gestures on macOS.#23663bpasero merged 10 commits intomicrosoft:masterfrom seivan:feature/swipe_between_tabs
Conversation
|
@seivan, |
|
@seivan should this work out of the box or do I need to configure my trackpad specifically? |
|
@bpasero It should work out of the box (with default macOS settings) but I'm not sure since I've changed my settings to this: |
|
@bpasero My take is it's an Electron issue if anything, since we're just listening to events here. |
Event: 'swipe' macOSReturns:
Emitted on 3-finger swipe. Possible directions are Emphasis mine. |
src/vs/code/electron-main/window.ts
Outdated
| }); | ||
|
|
||
| // Swipe command support (macOS) | ||
| this._win.on('swipe', (e, cmd) => { |
There was a problem hiding this comment.
@seivan can we reuse this code with the on('app-command') handler? Seems duplicate.
There was a problem hiding this comment.
@bpasero Read my mind. I thought about it but I wasn't sure you guys would want it. We could take an object of events and left/right options to compare to.
[{event: "swipe", leftAction :"...", rightAction:"..."}, ...]
or just call a function twice with the params. Up to you.
Is that OK with you?
There was a problem hiding this comment.
@seivan extracting the code to a function and calling it works for me best
|
@bpasero This seems like intended behaviour as Electron does not switch between |
|
@seivan makes sense, I asked on the related issue for more feedback from users. Otherwise your PR seems like the way to go (I added little bit of feedback). |
|
@seivan ping |
|
@bpasero I thought we were still waiting for feedback. My bad. I'll get it on later tonight. |
|
Thanks! |
…e method that defines back and forward commands.
|
@seivan the more I think about it the more I feel this should be controlled via a new setting so that users can opt-in to this feature and report back how it works. I suggest something like |
|
@bpasero Yeah that makes sense. I'll give it a go tomorrow. |
…ettings. Importing `IWorkbenchEditorConfiguration` to `window.ts` to listen settings before registering macOS Swipes. Refactoring `configurationRegistry` to setup properties first so it can use conditionals for macOS settings.
|
@bpasero I didn't have time to check, but do you 're-run' If you do not re-run |
|
@seivan yes you should listen to the settings change and adjust accordingly, see https://github.com/Microsoft/vscode/blob/master/src/vs/code/electron-main/window.ts#L246 for example how we do it there. |
|
@bpasero Sorry, I don't quite follow, could you show which specific callback to listen to? Your link seems outdated now. Is it Do I need one for the workBench? |
|
@seivan yes that is the right listener to use, it should be available on the main side to listen for config changes (maybe I did not understand your question properly?) |
|
@bpasero Just to clear the ambiguity, I am just not sure where I'm supposed to to use |
|
@seivan I would say you can maybe remove the swipe listener (or add it) based on the configuration change event, iff the value of this setting changes. So I would say that listening on this event around where you register the swipe listener is the right place. |
|
@bpasero Yeah, that's what I am asking; what's the method that triggers on configuration change? Will it also trigger on boot? So I can just keep it in one place? |
…ng swipe listeners. Also removed config argument from `getMenuBarVisibility()` since it wasn't being used.
|
@bpasero Alright, so I think I figured it out. Take a look, thanks! |
bpasero
left a comment
There was a problem hiding this comment.
Getting closer, some minor feedback included.
src/vs/code/electron-main/window.ts
Outdated
| } else if (cmd === forward) { | ||
| this.send('vscode:runAction', 'workbench.action.navigateForward'); | ||
| } else { | ||
| console.warn('[electron command]: did not handle: ', command); |
There was a problem hiding this comment.
Should not happen, please remove.
There was a problem hiding this comment.
The cmd is a string. It could technically happen? You want the warning removed?
There was a problem hiding this comment.
You could guard against this by using a string variable, e.g. 'foo' | 'bar' so that noone can pass anything else in.
There was a problem hiding this comment.
@bpasero We can't predict all the available commands for every event related to navigation that exists. You would have to maintain a list somewhere to keep them up to date.
E.g for swipe it's left and right but on app-command it's: browser-backward and browser-forward
There was a problem hiding this comment.
But we are the only ones calling this method, no? Why do we expect to print a warning? This is not API anyone else is using?
There was a problem hiding this comment.
@bpasero Imagining future navigation gestures that have unhandled cmds. It's up to you. If you want it gone, I'll remove it.
There was a problem hiding this comment.
Yeah, lets remove it for now, thanks 👍
src/vs/code/electron-main/window.ts
Outdated
|
|
||
| // Swipe command support (macOS) | ||
| const workbenchConfig = this.configurationService.getConfiguration<IWorkbenchEditorConfiguration>(); | ||
| if (workbenchConfig && workbenchConfig.workbench && workbenchConfig.workbench.editor.swipeBetweenOpenFiles) { |
There was a problem hiding this comment.
Careful here, workbenchConfig.workbench.editor can be null so we need another null check.
There was a problem hiding this comment.
Ah good point. I was thinking maybe they should be defined as optionals as I actually thought of doing that refactoring, but maybe that should be a different PR?
I feel having to do those checks without the compiler enforcing it is wrong per se.
But I'll get on this later tonight. Thanks for catching it!
Edit: Actually, editor can't be null, I remember testing it. workBench could be null and did throw, but editor wasn't. I am not exactly sure how this works though, so maybe you have better insights here.
There was a problem hiding this comment.
All of it can be null as soon as a user configures something like this in settings:
{
"editor": null
}There was a problem hiding this comment.
Ah I understand!
How do you feel about making this more inline with TS and using optionals? Should prevent future issues like this.
There was a problem hiding this comment.
@bpasero I can take that in a different PR if it would be of interest, basically the structure now could technically be changed to a class with optional attributes. It's just a regular object for now(?). I'll leave it and do the checks for now.
There was a problem hiding this comment.
We cannot change this, it is just a plain old object after all.
| }; | ||
|
|
||
| if (isMacintosh) { | ||
| workbenchProperties['workbench.editor.swipeBetweenOpenFiles'] = { |
There was a problem hiding this comment.
I am not a big fan of the naming swipeBetweenOpenFiles, because in reality you can swipe left and right between any editor that is opened, not just files. How about naming this workbench.editor.swipeToNavigate?
There was a problem hiding this comment.
@bpasero You're right, I'm not happy with the name either, changed it twice, lol.
Sure, that's a good call.
…ngs for unhandled commands for listener.
|
@bpasero Take another look. |
|
Thanks, looks good now! |



For #4803
Disabled by default, enabled with: