View Layout Customizations Part 4

[sbatten]

• Use unique ids for generated containers and remove source view info from cache use uuid and try dynamic titles #94686
• Settle on good icon/name strategy use uuid and try dynamic titles #94686 (needs more work)
• Handle views registered to container ids
• Allow moving whole containers around

[sbatten]

Planning Discussions

Debt

1. Use truly unique generated container ids and adopt a naming scheme that doesn't depend on the view that created it. (Current approach using the top most view)
2. Adding context to view titles. e.g. Debug: Variables when it is not in Debug.
3. Better handling of No Views in the Panel

Polish

1. Better multipanel experience
2. How to handle collapsed views in panel / sidebar
3. Revisit collapsing all views

Features

1. SCM Viewlet moving
2. Allow moving complete composites as a group
3. Container customization (backlog candidate)
4. Additional locations (not now)

Key Takeaways

1. Moving forward, containers will be ephemeral and lack identity on their own
2. Investigate popping out sidebar/activitybar/panel when dragging
3. How do we handle a view that is contributed to a container that doesn't "exist"?

[sandy081]

How do we handle a view that is contributed to a container that doesn't "exist"?

Does this goes into a generated container?

[sbatten]

Does this goes into a generated container?
Potentially. We could just generate a container for it, or we could do best effort, or we could change how view contributions work.

Concrete Example 1

1. I create an extension that contributes a Bing Search view to the search view container.
2. The user moves search into the Panel.
3. The user installs my extension.

Should Bing Search live in the panel with search? Does your answer change if the user put search into the explorer?

Concrete Example 2

cc @eamodio

1. User installs GitLens.
2. User moves all of the GitLens view into the panel.
3. GitLens adds a new view in the next release.

Should the new view appear in the original GitLens viewlet that no longer exists? Or worse, the user has put SCM in the gitlens viewlet and removed all GitLens views so therefore it really isn't GitLens anymore.

Proposal

One idea from 1:1 with Kai, view containers are removed from extension authoring. Rather, views are considered "adjacent" to another view. If an extension contributes a single view and does not specify an "adjacent" view, it will get a generated container using its icon. If a view specifies an adjacent view, it will default to the current location of that view.

[eamodio]

Not sure I'm a fan of that idea. Basically because it removes a nice logical grouping mechanism.

For example, in this proposal, GitLens would basically contribute 1 view (say Repositories) without an adjacent view, and then all the rest could be adjacent to that view. But now the container would be called Repositories and would have that view's icon rather than what I would want -- which would be GitLens and the GitLens icon.

It also creates greater dependency on view ids, which doesn't seem like a great thing to me, because changing a view id would then kind of be a breaking change.

[eamodio]

What if instead a container could be of a defined "container type". So viewsContainers contributions are really just defining a "container type", with an id, title, and icon, which could be "applied" to any container. Then as a user, as you move things around, they would create containers with the "specified" type if needed, and you could change the type of existing containers. This would allow the user to choose icons/titles and default locations for views contributed into "known" containers.

A user would also have the ability to "create" a custom container -- by allowing them to choose the title/icon themselves.

There might be a need to allow only one container of a type at a time, but I'm not sure it would be too big of a deal if there were multiple -- if that is what the user wanted.

This is more complex, but what if a view container could have a pre-defined "type" which could be
"explorer", "scm", "search", "debug", "custom" (or maybe custom is extension defined

[sbatten]

It also creates greater dependency on view ids, which doesn't seem like a great thing to me, because changing a view id would then kind of be a breaking change.

This is already the case for view container ids

but now the container would be called Repositories and would have that view's icon rather than what I would want -- which would be GitLens and the GitLens icon.

In this proposal, repositories view would have optional containerIcon and containerTitle properties to be GitLens

[sbatten]

For your proposal, I'm not sure I fully understand it. Could you explain how it would work with Concrete Example 1

[sandy081]

I would say new views or those which are not seen by user yet goes into their default locations. And user can move them after the fact they appear. IMO being too smart can lead to inconsistencies and confusions.

[sbatten]

I think the proposal is not about being too smart but rather changing the way we work in the future to match our end goal. Viewlets and Panels are no longer static concepts but created and destroyed at the users command. Built-in views are just examples and should not be static either. Consider that a company or school provisions VS Code on machines with a few extensions built-in. These viewlets are somehow treated differently than built-in? That doesn't make much sense to them.

[sbatten]

One thing of which I believe we are convinced is that view containers are ephemeral and lack self-identity. This is demonstrated by them having a meaningless identifier with no ties to their creator view. The next step in tackling this is understanding how we give these views identity. i.e. How do we pick icons and a name for them? As the plan item suggests, this will be dynamic. And lastly, we have a final thing to consider, which is how to handle the views which are contributed to a container that has been transformed by view movement.

Starting with the last issue, I propose the following plan:

If an extension view is contributed to a container:

1. Check if the container with that id exists. If yes, go to step 2, else step 3.
2. Check if the container has any view in it that was statically registered to it. If yes, go to step 4, else step 3.
3. Check if a container exists with all of the default views intended for the original container. If yes, go to step 4, else step 5.
4. Register to the container chosen in the previous step.
5. Generate a container for the view.

With the above logic in place, I think our dynamic view icons and titles can glean some behavior:

1. Containers should have affinity toward their own icon/title if they contain a view that was registered to them statically.
2. Otherwise, containers should use a title/icon from the top/left-most view.