Skip to content
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

Consistency with the use of "workspace" #77718

Open
jabacchetta opened this issue Jul 21, 2019 · 13 comments

Comments

@jabacchetta
Copy link

commented Jul 21, 2019

Problem

Developers don't know what a workspace is. Here's my recent attempt to clear up the confusion.

Confusion

  • The recent list widget groups folder workspaces along with .code-workspace workspaces under a "workspace" heading, indicating that everything in that list is a workspace. Then it gives .code-workspace workspaces a "Workspace" suffix, contradicting the header, and indicating that only those workspaces that are associated with a .code-workspace file are true workspaces.

  • The first interaction with the term "workspace" for most developers is going to be the workspace settings. This is setting up users for confusion right off the bat. Because a folder's .vscode settings is initially referred to as "Workspace" settings. But when a .code-workspace file is created, .vscode settings becomes "Folder" settings, while the .code-workspace settings becomes the new "Workspace" settings.

  • "Open Workspace" is referring to a .code-workspace workspace (with the dialog only allowing a .code-workspace file to be selected). Same goes for "Add Folder to Workspace..." and "Save Workspace As...".

  • An extension's "Disable (Workspace)" option is referring to workspace as defined by my definition in the SO post.

Suggestion

NOTE: Suggestions will be updated as discussion in this thread evolves.

  • In the recent list widget, create two separate headings: "Workspace" and "Folder". Remove suffixes.
  • In settings editor, always refer to specific settings with the same reference. "Workspace" tab for .code-workspace settings. "Folder" tab for .vscode settings.
  • "Open Workspace", "Add Folder to Workspace...", and "Save Workspace As..." remain unchanged.
  • An extension's context menu will show "Disable (Workspace)" or "Disable (Folder)" depending on which is currently active.
  • Optionally, come up with another term when wanting to reference both definitions. Whether it's "Project" or something else. Then it would be acceptable to use "Disable (Project)" in the extension's context menu, for example.
@bpasero

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

I think we have to be careful to call this "multi root workspace" because you can easily have just one (or actually no) folder in a workspace file. The use case is still that it allows you to store workspace settings for this folder without polluting the folder with a .vscode folder.

@bpasero bpasero self-assigned this Aug 5, 2019
@jabacchetta

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

Yeah, naming this will be tough. Although I do think that consistency across the UI is more important than the naming itself.

What about referring to everything as "Projects", and then in the recent list widget, for example, changing the heading to "Projects", and giving those projects a suffix "Workspace" for .code-workspace files and "Folders" for single folder projects?

Same goes for the settings... "Workspace" and "Folder" settings, with "Folder" always being used to refer to settings that exist inside a .vscode folder and "Workspace" always being used to refer to settings that exist in a .code-workspace file (as opposed to changing the naming and creating confusion when a .code-workspace file is created).

And then when enabling/disabling extensions, "enable for this project".

@bpasero

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

But why would we introduce something new ("Project") that was never used in VSCode so far at all? I do not want to bring in the notion of projects because the next question will be, what kind of project systems we support etc.

@jabacchetta

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

Another option:

In the recent list widget, separate them out into two different headings: "Workspace" and "Folder", and remove suffixes all together.

Again, "Workspace" and "Folder tabs in the settings, with "Folder" always being used for settings coming from the .vscode folder.

For enabling/disabling extensions, I suppose it would need to be dynamic. "Enable for this workspace" when a workspace is opened, and "Enable for this folder" otherwise.

At this point, I'm starting to confuse myself, lol.

@bpasero

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

We decided to call both single folders and workspace file the "workspace" you are in. You could name the one "single-folder workspace" and the other "multi-root workspace", but then again, a multi-root workspace can have 0-1 roots too.

@jabacchetta

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

What about the UI inconsistencies mentioned above?

  • Will suffixes be removed in the recent list widget? If referring to both as "Workspaces", then the .code-workspace projects shouldn't have a "Workspace" suffix that would indicate that only those are workspaces.
  • When opening a .code-workspace file, what will settings tabs look like? Will what was once referred to as "workspace" settings become "folder" settings still?
  • What will "Open Workspace" menu item become? In other words, it wouldn't make sense to refer to both a single folder project with a .vscode folder and a project that's associated with a .code-workspace file as a Workspace, but then have an option for opening a workspace that only allows you to choose a .code-workspace file.
@bpasero

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

"Open Workspace" and "Open Folder" are still there so that we can filter the dialog. With our custom dialog it would probably be possibly to be smarter here.

I refer to @sandy081 for settings.

@jabacchetta

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

Yeah, I definitely understand the need to filter the dialog, but again, this is a UI inconsistency that is going to confuse users. At times, both are being referred to as a workspace. At other times, the UI is using the term workspace to refer only to projects associated with a .code-workspace file.

I think, looking through the forum posts that I linked to, it's clear that this has become a confusing issue. Even the answers to those questions are all over the map. And the UI inconsistencies are the biggest cause of this confusion.

@jabacchetta

This comment has been minimized.

Copy link
Author

commented Aug 10, 2019

Expanding on earlier suggestion:

  • In the recent list widget, create two separate headings: "Workspace" and "Folder". Remove suffixes.
  • In settings editor, always refer to specific settings with the same reference. "Workspace" tab for .code-workspace settings. "Folder" tab for .vscode settings.
  • "Open Workspace", "Add Folder to Workspace...", and "Save Workspace As..." remain unchanged.
  • An extension's context menu will show either "Disable (Workspace)" or "Disable (Folder)" depending on which is currently open.
  • Optionally, come up with another term when wanting to reference both definitions. Whether it's "Project" or something else. Then it would be acceptable to use "Disable (Project)" in the extension's context menu, for example.
@sandy081

This comment has been minimized.

Copy link
Member

commented Aug 14, 2019

I agree it makes sense to call settings from a folder always Folder settings which makes it consistent across single folder and multi root folder workspace.

@roblourens FYI

@andrecasal

This comment has been minimized.

Copy link

commented Oct 8, 2019

I think it would make a lot of intuitive sense to explain that VS Code assumes that any opened folders are an implicit workspace and that we have the ability to create an explicit workspace as a .code-workspace file.

Something like this:
VS Code assumes any opened folders as an implicit workspace and settings for each root folder go inside each root's /.vscode folder. We can also create an explicit workspace as a .code-workspace file which can contain none or more root folders. An explicit workspace .code-workspace file without any root folders can be used to save custom settings, useful for remote development for example, or with multiple root folders where you might have a repository with your product's source code along with the product's documentation which you'd like to keep current. There is no advantage to an explicit workspace .code-workspace file with only one root folder over an implicit workspace that automatically reads settings from the /.vscode folder, however (right?).

I suggest we use implicit workspace and explicit workspace to differentiate between the two use-cases.

@nemchik

This comment has been minimized.

Copy link

commented Oct 8, 2019

I wouldn't mind to see Project Folders added to Workspaces (where a workspace is the vscode workspace and a project folder gets added to your tree).

With that in mind, some people may choose to run a single project per workspace. That's up to each person to decide how they want their root.

@edburns

This comment has been minimized.

Copy link

commented Oct 12, 2019

I just submitted a PR to address the documentation side of this issue: microsoft/vscode-docs#3154 . Please consider it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.