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

Fix #9203: Drag and drop sections between views #9644

Merged
merged 7 commits into from
Oct 6, 2021

Conversation

EstherPerelman
Copy link
Contributor

@EstherPerelman EstherPerelman commented Jun 27, 2021

Signed-off-by: Esther Perelman [email protected]

This PR enable to group multiple views at the same container without the need to navigate between the containers

What it does

Fix #9203

How to test

  1. Install Docker extension & Gitlens extension (available in theia Extensions view).

  2. Run the command (ctrl + shift + p): View: Reset Workbench Layout

  3. Try Drag & Drop views between containers:
    DND sample

  4. Attentions:

    • d&d for Extensions view is disabled (as vscode).
    • dragging is allowed only inside the container for: File explorer view part and debug view parts (you still able to drop views from other containers on those parts)
    • restore last containers views after f5 should work.

Review checklist

Reminder for reviewers

@EstherPerelman EstherPerelman force-pushed the drag-and-drop branch 2 times, most recently from 4c457c5 to 2787877 Compare June 28, 2021 08:28
@colin-grant-work
Copy link
Contributor

@EstherPerelman, are you still having trouble with the Search-in-Workspace widget? When I pull your code, I'm able to search and get results. However, I'm not able to drop anything in that widget. Have you removed the code that placed it in a ViewContainer?

@EstherPerelman
Copy link
Contributor Author

@EstherPerelman, are you still having trouble with the Search-in-Workspace widget? When I pull your code, I'm able to search and get results. However, I'm not able to drop anything in that widget. Have you removed the code that placed it in a ViewContainer?

@colin-grant-work Thank for trying to help! I'm still having this trouble, It's very strange I haven't removed any code - for me it still enables dropping into it but not showing the search results, Do the other containers enable d&d for you?

@EstherPerelman
Copy link
Contributor Author

Hi all, If there's no solution for fixing the problem with search container - is it possible to push it without the ability to use the dnd inside search container?
cc @colin-grant-work

@colin-grant-work colin-grant-work self-requested a review July 13, 2021 12:52
Copy link
Contributor

@colin-grant-work colin-grant-work left a comment

Choose a reason for hiding this comment

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

With minor exceptions (one immediately below, and one in the comments), both of them apparently related to the special status of the debug session widget, this is working pretty well for me. The logic for identifying and moving parts is pretty involved, but I don't see any easy simplifications. I will see if I can work out what's going on with the search-in-workspace widget - I suspect that it's another special case - but I have no objection in principle to merging this and leaving the SIW as a later to-do.

I got somewhat inconsistent behavior with the highlighting for drop. In a plugin view container (GitLens, in my case), and the internal SCM widget, I got highlighting when dropping parts from other containers. However, in the debug view container, after collapsing all of the parts, there was no highlighting when I dragged parts from other containers. The drop functionality still worked fine, though.

packages/core/src/browser/style/tabs.css Outdated Show resolved Hide resolved
packages/core/src/browser/view-container.ts Show resolved Hide resolved
packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
packages/core/src/browser/view-container.ts Show resolved Hide resolved
packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
@colin-grant-work
Copy link
Contributor

colin-grant-work commented Jul 13, 2021

@EstherPerelman, I think the Search-in-Workspace widget is actually fine and the problem is only styling - the tree is ending up with a height of 0px. Going through the element tree and adding height: 100% to the tree container and its parents until they showed up seemed to fix the problem - fiddle around with the CSS to find the most parsimonious solution.
image

@vince-fugnitto vince-fugnitto added tree issues related to the tree (ex: tree widget) vscode issues related to VSCode compatibility labels Jul 16, 2021
@EstherPerelman
Copy link
Contributor Author

EstherPerelman commented Jul 26, 2021

@colin-grant-work Thank you so much for the help and review! setting the height of search-in-workspace to 100% did solve the problem!
I added more fixes and solved according to your comments...
Thanks👍
(Responds late because I haven't been at work for a week...)

@EstherPerelman EstherPerelman marked this pull request as draft July 28, 2021 07:22
@colin-grant-work
Copy link
Contributor

This is working very nicely for me. Now only the comments about the shifting icons and references to debug in core remain. 👍

@EstherPerelman
Copy link
Contributor Author

This is working very nicely for me. Now only the comments about the shifting icons and references to debug in core remain. 👍

Great! I'm still working on this because the restore after refresh(f5) not working well, I still didn't succeed to see it working perfect, Maybe adding a ViewContainerManager will solve the problem...

@EstherPerelman EstherPerelman marked this pull request as ready for review August 11, 2021 15:12
@EstherPerelman
Copy link
Contributor Author

EstherPerelman commented Aug 11, 2021

@colin-grant-work

  • A:

If possible, we should avoid referring to anything related to debug in core. Perhaps define an interface here that the debug widget could implement that would get around these problems?

I have started to implement as you wrote but saw that it doesn't fit all places (where I have only the ViewContainer widget without information about the parent parent ...), Anyway I have found a solution by creating draggingPartManager which make things easier...

  • B:

I think the problem still exists. I think we probably need to set the box-sizing property for these tabs to be border-box (hopefully that will fix it - it may be more complex)

I have spent time on this but box-sizing setting and others just didn't solve it (while setting outline instead of border the icon didn't move but the appearance was not uniform)

  • C:

Restore after refresh suppose to work well now...

Finally
Only one issue remains: the border style that cause the icons to move...

@EstherPerelman EstherPerelman force-pushed the drag-and-drop branch 2 times, most recently from 4212b43 to cb3f559 Compare August 11, 2021 16:19
@EstherPerelman
Copy link
Contributor Author

@colin-grant-work
I found a solution for the issue with the border
So - the PR is full ready now for another review
Thanks for all advices and comments

Copy link
Member

@msujew msujew left a comment

Choose a reason for hiding this comment

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

Great work. I almost wanted to approve, until I noticed an issue with reloading the browser application. This happens both on firefox and chrome:

dnd.mp4

As you can see, after reloading and moving a section the view becomes kind of unresponsive and multiple sections try to move into the same space. This issue persists after reloading and can only be resolved by resetting the layout.

@colin-grant-work
Copy link
Contributor

Another VSCode feature that doesn't necessarily need to be implemented here, but that you may want to consider is the draggability of parts that are the sole child of their view container. E.g. in VSCode, if the Search-in-Workspace widget is the sole child of the search container, you can start a drag on the ViewContainer title that behaves the same as dragging the ViewContainerPart's title.

@EstherPerelman
Copy link
Contributor Author

EstherPerelman commented Aug 12, 2021

Another VSCode feature that doesn't necessarily need to be implemented here, but that you may want to consider is the draggability of parts that are the sole child of their view container. E.g. in VSCode, if the Search-in-Workspace widget is the sole child of the search container, you can start a drag on the ViewContainer title that behaves the same as dragging the ViewContainerPart's title.

@colin-grant-work I know about this, it also available in vscode to drop the part header on the sidebar and a new tab will be created,
I'm afraid of the mess with creating new viewContainers, I'll need to create a new id to a duplicate container - then to get it by this id in other places... don't know how it can be managed easily

@colin-grant-work
Copy link
Contributor

@colin-grant-work I know about this, it also available vscode to drop the part header on the sidebar and a new tab will be created,
I'm afraid of the mess with creating new viewContainers, I'll need to create a new id to a duplicate container - then to get it by this id in other places... don't know how it can be managed...

It sounds reasonable to omit this for now. I only noticed its absence because I was having trouble finding anything to drag, without the debug widgets being draggable :-).

@EstherPerelman
Copy link
Contributor Author

EstherPerelman commented Aug 12, 2021

Great work. I almost wanted to approve, until I noticed an issue with reloading the browser application. This happens both on firefox and chrome:

@msujew thanks for review & almost approving;) hopping to resolve this soon, I find it little difficult to fix (I'm not familiar with the containerLayout handles and sizes behavior) if you know about something that might help I'll be happy to see...

@EstherPerelman
Copy link
Contributor Author

Actually if there will be no solution we are able to completely disable drag & drop for the debugger container (which is the only one who makes these troubles) as done for Extensions, WDYS?
(I have already fixed all other issues)

@msujew @colin-grant-work

@EstherPerelman
Copy link
Contributor Author

EstherPerelman commented Sep 12, 2021

@colin-grant-work I have addressed the issue with search icon and the next issues:

I'm seeing one odd behavior. It looks like the git decorations for modified files remain attached to the Source Control View Container even if you move the source control widget out of that container:

I have pushed a commit that supports the decorations moves, But It doesn't work for the widgets that move into the debug container.

Another minor oddity:

  1. Move another view into the Search container
  2. Collapse the Search-in-Workspace widget
  3. Use ctrl+shift+f to activate the Search-in-Workspace widget.
  4. Observe that its title bar is highlighted, but the widget remains collapsed.

I have added a code that opens the part on activating the widget by ctrl+shift+f / ctrl+shift+g / etc...

@colin-grant-work
Copy link
Contributor

colin-grant-work commented Sep 13, 2021

Both of the new behaviors are working for me 👍. @msujew, @vince-fugnitto, would you mind confirming that the bad behaviors have been addressed and there are no new regressions?

One thing I realized recently is that the highlight behavior in VSCode (adding a white bar above or below the icon) isn't actually connected to the dragging between containers, but to general drag-drop repositioning behavior, since in VSCode you can drop a ViewContainerPart on the main tabbar, and it will create a new ViewContainer. In Phosphor, the repositioning drag-drop is handled by shifting the icons around to open space for a repositioning. In this context, that's an undesirable behavior, because we want to drop in a container, not between container icons. We may need to rethink one or the other of these drag behaviors if we implement VSCode's full set of interactive possibilities.

packages/core/src/browser/view-container.ts Outdated Show resolved Hide resolved
@injectable()
export class SearchInWorkspaceFactory implements WidgetFactory {

static ID = SEARCH_VIEW_CONTAINER_ID;
Copy link
Member

Choose a reason for hiding this comment

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

@EstherPerelman the static ID can be removed it is not used, and we already export the constant SEARCH_VIEW_CONTAINER_ID. We should either use the constant, or the static ID but not both.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@vince-fugnitto I fixed it, It just the same as done in NavigatorWidgetFactory...

packages/core/src/browser/shell/tab-bars.ts Outdated Show resolved Hide resolved
@EstherPerelman
Copy link
Contributor Author

One thing I realized recently is that the highlight behavior in VSCode (adding a white bar above or below the icon) isn't actually connected to the dragging between containers, but to general drag-drop repositioning behavior, since in VSCode you can drop a ViewContainerPart on the main tabbar, and it will create a new ViewContainer. In Phosphor, the repositioning drag-drop is handled by shifting the icons around to open space for a repositioning. In this context, that's an undesirable behavior, because we want to drop in a container, not between container icons. We may need to rethink one or the other of these drag behaviors if we implement VSCode's full set of interactive possibilities.

@vince-fugnitto absolutely right! I still think these bars gives the user more indication on the dragging but I can remove it if you want to...

@colin-grant-work
Copy link
Contributor

@vince-fugnitto absolutely right! I still think these bars gives the user more indication on the dragging but I can remove it if you want to...

No, I think the bars are the more future-proof version of the drag-drop marker. Eventually, we will want to be able to drop both inside of and next to, and only the bars - not the shifting behavior - will allow that. Just something for the person who implements the next round to think about 🙂.

packages/core/src/browser/shell/tab-bar-decorator.ts Outdated Show resolved Hide resolved
packages/core/src/browser/shell/application-shell.ts Outdated Show resolved Hide resolved
Copy link
Member

@msujew msujew left a comment

Choose a reason for hiding this comment

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

It seems to work well in Chrome now, but there's some strange behavior in Firefox (92.0):

dnd-firefox.mp4

As soon as I let the mouse button go, it starts dragging correctly. But before letting go, the dragged container stays at the same place.

@EstherPerelman
Copy link
Contributor Author

EstherPerelman commented Sep 29, 2021

It seems to work well in Chrome now, but there's some strange behavior in Firefox (92.0):

@msujew thanks for finding that, I called the event preventDefault which seems to solve it. (sorry for the late answer, from now on I am available)

Can you merge it for tomorrow release?
cc @colin-grant-work @vince-fugnitto

Copy link
Member

@msujew msujew left a comment

Choose a reason for hiding this comment

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

Alright, looks good to me 👍

@vince-fugnitto
Copy link
Member

Can you merge it for tomorrow release? cc @colin-grant-work @vince-fugnitto

@EstherPerelman last release we had a couple of major regressions after merging big pull-requests late in the month (resulted in two patch releases). Should we instead wait till right after the release so we have the month to discover any possible regressions? In any case I'll still have to take the time to re-review the code and functionality before approving.

@EstherPerelman
Copy link
Contributor Author

Can you merge it for tomorrow release? cc @colin-grant-work @vince-fugnitto

@EstherPerelman last release we had a couple of major regressions after merging big pull-requests late in the month (resulted in two patch releases). Should we instead wait till right after the release so we have the month to discover any possible regressions? In any case I'll still have to take the time to re-review the code and functionality before approving.

@vince-fugnitto you are right, I also think it's better to wait after the release in case of regressions, Thank you!

@EstherPerelman
Copy link
Contributor Author

@colin-grant-work / @vince-fugnitto, Please notify me before merging so I'll resolve conflicts..

@EstherPerelman
Copy link
Contributor Author

@vince-fugnitto why don't you merge it? I don't want to wait till the end of the month...

@vince-fugnitto
Copy link
Member

@vince-fugnitto why don't you merge it? I don't want to wait till the end of the month...

@EstherPerelman I set time aside to be able to test the pr again first (I had never approved) #9644 (comment).

In any case I'll still have to take the time to re-review the code and functionality before approving.

@vince-fugnitto vince-fugnitto dismissed their stale review October 6, 2021 12:51

Stale Review

Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

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

I'm fine with the changes, we can fix any possible regressions during the month 👍
@colin-grant-work please merge if you are comfortable with the updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tree issues related to the tree (ex: tree widget) vscode issues related to VSCode compatibility
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Drag and drop sections between views
5 participants