Closed miguelsolorio closed 5 years ago
This issue for OS specific settings would likely be important for a settings sync UX: https://github.com/microsoft/vscode/issues/5595
Here's a spot where Settings Sync is lacking: it doesn't sync remote extensions. It's also missing platform-specific settings AFAIK. Other than that, it has a decent UX, especially with the new Sign in with GitHub feature. It should be a good starting point for this UX exploration.
"Sync pragmas" are also an essential feature for me because window.zoomLevel
is different on each of my computers and that specific setting "cannot" be synced. With Settings Sync, the syntax looks like this:
{
// @sync-ignore
"window.zoomLevel": "1",
}
BTW, is this being worked on with @shanalikhan, the author of Settings Sync? His extension is the de-facto standard in VSCode ecosystem and he probably heard about every possible feature request there might be 😄.
@maxencefrenette @borekb we have a line item that covers machine/OS only settings
Ah, you're right, I missed that.
BTW, what I like about Settings Sync is that it uses a "dumb" server-side storage so I'm not locked into any particular "smart" backend. When you mention this:
This exploration will aim to support syncing you settings [...] across multiple machines (local and remote) using a sign in service (account).
I'd like that "sign in service" to be GitHub, not a hypothetical "VSCode Account" (which would be similar to how JetBrains IDEs sync their settings).
Gist is a beautifully simple backend for sync – I can see how my settings evolved over time, can decide whether it's public or private, etc.
It's exciting that VSCode is adding this natively!
The problem being addressed is that users don't have an easy way to sync these settings
Fair enough...
and have to rely on third party extensions.
errrr.... isn't that the point of 3rd party extensions, though? Why reinvent the wheel here? Unless there's some significant benefit to integrating this directly into Code, wouldn't it be better all around to work with the Settings Sync extension author to address its current limitations?
@borekb The sign in service can be any (Github, Azure). VS Code will not hardcode to a particular account. We are planing to provide an API for extensions to register backend providers for sign-in and user data. See https://github.com/microsoft/vscode/issues/78966.
So, VS Code will control only what user data to sync and the corresponding UI. The complete backend for storing user data comes from extensions.
It means, the settings sync extension can still use github gist as backend but VS Code drives the UI.
@rossipedia Yes and No. Please see my above comment. User data synch still happens through third party extensions. VS Code does the synchronisation using user data provided by extensions. Since VS Code knows what to sync it is best to let VS Code makes this decision instead of extensions.
Yes we are looking to the settings synch extension from @shanalikhan as a reference and to make sure it can be adopted to new API without missing functionality.
It means, the settings sync extension can still use github gist as backend but VS Code drives the UI.
Awesome, that's the best way I could hope for. Thanks!
Okay, its great to see UX provided by VSCode itself and allow extensions to wrap their own system.
I would suggest you to provide some of the API alongwith the UX when we talk about "Settings Synch" in general.
I have few questions in general for some of which there are already seperate issues opened. I'm merging all of them here to allow us to see bigger picture.
Settings Sync needs to manually find the User
path for each of the code variant. Initially Settings Sync had to hard code the paths but now although its very much improved. Settings Sync still uses some techniques to find the User
folder and Extension
folder as written here I would suggest to allow authors to read the User
folder directly by just an API.
Extension Synch is not completely supported until extension.all
is updated after code restarts. I would suggest to either improve that or provide API to catch them. Reference : https://github.com/microsoft/vscode/issues/14444
Currently Settings Sync cannot disable / enable the extensions due to the limitations from the API. I would request to provide API for that. Reference : #15466
These are the some improvement i see from the API side to allow Settings Sync extension to fully utilize its power and increase productivity.
Now talking about adding UX. I would like to see the following things in the UX
Settings Sync has these configuration of its own, i would like to see this a part of Code so extension authors wont have to manage this.
As suggested by @borekb (https://github.com/microsoft/vscode/issues/78869#issuecomment-520881601) "Sync Pragmas" are essential part of Settings Sync, i would suggest to provide UX to allow me to see which Settings needs to be ignored by Settings Sync.
Provide UX to allow users to include workspace settings in a part of Sync. Settings Sync supports it. Reference : here
At the end, how you guys will enforce the newly made API. I would suggest you to send PR to allow Settings Sync to integrate complely with the new UX. It would take time from my side to integrate the new UX.
I have recenly added new UX in Settings Sync that integrates the Github. This UI needs to be integrated with your UX to let Settings Sync only manage the external storage part and keep the permissions and configurations to Code UI.
These are the initial things that comes to my mind.
Moving API discussion to https://github.com/microsoft/vscode/issues/78966
Here's a quick update on our progress. Right now we're focusing our efforts on creating a simple MVP experience that will accomplish the basics of syncing extensions/setting, and resolving conflicts.
This experience focuses on setting up the Sync feature, selecting what items to sync (Settings and Extensions), logging in with a Microsoft or GitHub account, and starting the sync experience.
This experience is exactly the same as the first, except that if you have additional extensions/settings on the second machine that aren't on the first one that is synced, it will merge them together.
This is a scenario that (we hope) won't happen very often. We'll always attempt to merge your settings without user input. However, in the case that you change the same setting on both machines to different values (be it from going offline or other connection issues), then we will notify you of conflicts and allow you to decide which value to choose from using our git merge conflict UI.
@misolori That looks awesome! Out of curiosity, are those gifs produced by some super-powered wireframe app, or is it real VSCode with some "sketchy theme"?
@borekb I use Figma to create all of my mockups and I have a wireframe library that I use to create these types mockups/prototypes.
It's awesome that it can also do these little interactions. Thanks for sharing!
Huge praise to Shan for his extensions but I'm also very glad to see this type of functionality finally being proposed to be brought into the main vscode project. It is badly needed.
Shans work is tireless. Even so it still messed up from time to time and I can get can wonky inexplicable results.
Please devs! Please bring this in natively to vscode by default!
The ux exploration phase of this feature has been completed as posted in https://github.com/microsoft/vscode/issues/78869#issuecomment-533740254. Development will continue and updates will be posted in the API Discussion issue https://github.com/microsoft/vscode/issues/78966.
Summary
This exploration will aim to support syncing you settings, extensions, keybindings, and snippets across multiple machines (local and remote) using a sign in service (account). The problem being addressed is that users don't have an easy way to sync these settings and have to rely on third party extensions. The primary scenarios we're looking to address are:
Related Issues
Current Experience
Users have to rely on third-party extensions (like Settings Sync) to have syncing across machines. For remote scenarios, users have to manually install extensions on those machines (see below).