Skip to content

Add movable property to views and add toggle view commands #88823

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

Merged
merged 15 commits into from
Jan 23, 2020
Merged

Add movable property to views and add toggle view commands #88823

merged 15 commits into from
Jan 23, 2020

Conversation

sbatten
Copy link
Member

@sbatten sbatten commented Jan 17, 2020

refs #85164

this is not compiling right now because i paused in the middle of a change.

@sandy081 this is just a PR so you can see where my head is at. There are lot of things hacked together to see this working and play with different ideas while I sort it out. The most hacky stuff comes around where we actually surface the menu entries. I notice that panel headers do not have the same context menu luxuries that the viewlet has due to the composite bar and view headers being a combined concept for panel.

Notes from implementation:

  1. It seems the view descriptor service should be responsible for generating the view containers when a view is moved to the panel without a destination. this is important because of the next point.

Update: Moved logic into the service and moved service to its own filed due to cyclic dependency issue.

  1. when a view is moved to the panel and then the window is reloaded, the view descriptor service needs to be able to create the cached view container at the point of the views registration because the container was created on the fly previously.

  2. the cache may need to be enhanced to store that a cached view container was auto-generated and not registered the traditional way as well as the location info about that view container so it can be recreated.

Update: the cache now stores the id of the container along with its source view id and location if it is auto generated.

  1. these on-the-fly view containers should not be too custom to the view that created them because it is possible in the future that a view is moved to the panel to create container A. another view is moved to container A. the first view is moved back to the sidebar leaving the second view in container A. On reload, we need to be able to recreate container A preferably without too much knowledge about the view that created it since we don't have that information anymore.

Update: by using the source view id to regenerate the id, we assume that the source view will be registered at some point. if it is not, we move the pending view back to its default location. this is the same logic as containers contributed by extensions.

/Cc @isidorn

@sbatten sbatten self-assigned this Jan 17, 2020
@sbatten sbatten added this to the January 2020 milestone Jan 17, 2020
@sbatten
Copy link
Member Author

sbatten commented Jan 17, 2020

see update to description

if (viewDescriptor.canMoveView) {
result.push(<IAction>{
id: `${viewDescriptor.id}.removeView`,
label: this.isViewMergedWithContainer() ? nls.localize('toggleSpecificViewLocation', "Toggle {0} View Location", viewDescriptor.name) : nls.localize('toggleViewLocation', "Toggle View Location"),
Copy link
Member

Choose a reason for hiding this comment

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

Why not show the view name always?

@sbatten sbatten marked this pull request as ready for review January 23, 2020 03:00
@sbatten sbatten requested a review from sandy081 January 23, 2020 03:00
@sbatten
Copy link
Member Author

sbatten commented Jan 23, 2020

@sandy081 updated with what we discussed. one issue that arose with the panel context menu entry is that we can only get this entry information once the panel (meaning the specific composite) has been instantiated. with that limitation, the move to sidebar command will only show when you right click the active panel header. this is still much better than how it was working this morning.

If you have any desired changes, feel free to make them and merge the PR.

@sandy081
Copy link
Member

@sbatten Did following changes

  • Introduced ViewTitleContext menu id to contribute title context menu actions.
  • ViewsService contributes move view actions to this menu id with proper when contexts.
  • ViewPane provides context menu actions using this menu id
  • ViewPaneContainer gets the context menu actions from the ViewPane if asked for a view.
  • PanelPart has a special case for now. It does not got to ViewPaneContainer instead it gets actions directly from above menu id for the context menu actions of a view. This fixes not showing move action on a non active panel.
  • And other small refactorings.

@sandy081
Copy link
Member

Merging!!!

@sandy081 sandy081 merged commit 1a5ffab into microsoft:master Jan 23, 2020
@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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants