Skip to content

Fixes #4803: Adding support for swipe gestures on macOS.#23663

Merged
bpasero merged 10 commits intomicrosoft:masterfrom
seivan:feature/swipe_between_tabs
Apr 19, 2017
Merged

Fixes #4803: Adding support for swipe gestures on macOS.#23663
bpasero merged 10 commits intomicrosoft:masterfrom
seivan:feature/swipe_between_tabs

Conversation

@seivan
Copy link
Contributor

@seivan seivan commented Mar 30, 2017

For #4803

Disabled by default, enabled with:

"workbench.editor.swipeToNavigate": true

vscode

@mention-bot
Copy link

@seivan, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bpasero and @egamma to be potential reviewers.

@msftclas
Copy link

@seivan,
Thanks for having already signed the Contribution License Agreement. Your agreement has not been validated yet. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@bpasero
Copy link
Member

bpasero commented Mar 30, 2017

@seivan should this work out of the box or do I need to configure my trackpad specifically?

@seivan
Copy link
Contributor Author

seivan commented Mar 30, 2017

@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:

screen shot 2017-03-31 at 01 00 46

@bpasero
Copy link
Member

bpasero commented Mar 30, 2017

It seems to me this does not work when trackpad is configured like this:

image

@seivan
Copy link
Contributor Author

seivan commented Mar 30, 2017

@bpasero My take is it's an Electron issue if anything, since we're just listening to events here.

@seivan
Copy link
Contributor Author

seivan commented Mar 30, 2017

Event: 'swipe' macOS

Returns:

  • event Event
  • direction String

Emitted on 3-finger swipe. Possible directions are up, right, down, left.

Emphasis mine.

@bpasero
Copy link
Member

bpasero commented Mar 30, 2017

Ok the only way I get this to work is with the following config:

image

Does somebody know if that is the default on macOS?

});

// Swipe command support (macOS)
this._win.on('swipe', (e, cmd) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seivan can we reuse this code with the on('app-command') handler? Seems duplicate.

Copy link
Contributor Author

@seivan seivan Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seivan extracting the code to a function and calling it works for me best

@seivan
Copy link
Contributor Author

seivan commented Mar 30, 2017

@bpasero This seems like intended behaviour as Electron does not switch between full-screen apps but between pages and it needs three fingers as two fingers is scrolling.

@bpasero
Copy link
Member

bpasero commented Mar 30, 2017

@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).

@bpasero
Copy link
Member

bpasero commented Apr 6, 2017

@seivan ping

@seivan
Copy link
Contributor Author

seivan commented Apr 6, 2017

@bpasero I thought we were still waiting for feedback. My bad. I'll get it on later tonight.

@bpasero
Copy link
Member

bpasero commented Apr 6, 2017

Thanks!

…e method that defines back and forward commands.
@bpasero
Copy link
Member

bpasero commented Apr 7, 2017

@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 workbench.swipeToNavgiate (boolean) and wire it up. You can see for other settings like window.titleBarStyle how this is wired up.

@seivan
Copy link
Contributor Author

seivan commented Apr 7, 2017

@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.
@seivan
Copy link
Contributor Author

seivan commented Apr 7, 2017

@bpasero I didn't have time to check, but do you 're-run' registerListeners() on settings change?
Or do you need to trigger a function on setting changes?

If you do not re-run registerListeners() then I need to listen to setting changes to remove the swipe-listener, not sure where to find those.

@bpasero
Copy link
Member

bpasero commented Apr 7, 2017

@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.

@seivan
Copy link
Contributor Author

seivan commented Apr 12, 2017

@bpasero Sorry, I don't quite follow, could you show which specific callback to listen to? Your link seems outdated now.

Is it

this.onConfigurationUpdated(this.configurationService.getConfiguration<IConfiguration>());

Do I need one for the workBench?

@bpasero
Copy link
Member

bpasero commented Apr 12, 2017

@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?)

@seivan
Copy link
Contributor Author

seivan commented Apr 12, 2017

@bpasero Just to clear the ambiguity, I am just not sure where I'm supposed to to use this.onConfigurationUpdated { .... }  and check for enable/disable and set the listener or remove it?

@bpasero
Copy link
Member

bpasero commented Apr 12, 2017

@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.

@seivan
Copy link
Contributor Author

seivan commented Apr 16, 2017

@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.
@seivan
Copy link
Contributor Author

seivan commented Apr 16, 2017

@bpasero Alright, so I think I figured it out. Take a look, thanks!

Copy link
Member

@bpasero bpasero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting closer, some minor feedback included.

} else if (cmd === forward) {
this.send('vscode:runAction', 'workbench.action.navigateForward');
} else {
console.warn('[electron command]: did not handle: ', command);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not happen, please remove.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cmd is a string. It could technically happen? You want the warning removed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could guard against this by using a string variable, e.g. 'foo' | 'bar' so that noone can pass anything else in.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Member

@bpasero bpasero Apr 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bpasero Imagining future navigation gestures that have unhandled cmds. It's up to you. If you want it gone, I'll remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, lets remove it for now, thanks 👍


// Swipe command support (macOS)
const workbenchConfig = this.configurationService.getConfiguration<IWorkbenchEditorConfiguration>();
if (workbenchConfig && workbenchConfig.workbench && workbenchConfig.workbench.editor.swipeBetweenOpenFiles) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Careful here, workbenchConfig.workbench.editor can be null so we need another null check.

Copy link
Contributor Author

@seivan seivan Apr 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@bpasero bpasero Apr 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of it can be null as soon as a user configures something like this in settings:

{
   "editor": null
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I understand!
How do you feel about making this more inline with TS and using optionals? Should prevent future issues like this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like how?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot change this, it is just a plain old object after all.

};

if (isMacintosh) {
workbenchProperties['workbench.editor.swipeBetweenOpenFiles'] = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bpasero You're right, I'm not happy with the name either, changed it twice, lol.
Sure, that's a good call.

@seivan
Copy link
Contributor Author

seivan commented Apr 18, 2017

@bpasero Take another look.

@bpasero
Copy link
Member

bpasero commented Apr 19, 2017

Thanks, looks good now!

@bpasero bpasero merged commit bd84e6d into microsoft:master Apr 19, 2017
@bpasero bpasero added this to the April 2017 milestone Apr 19, 2017
@github-actions github-actions bot locked and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants