Add drag and drop for contributed tree views

[Krzysztof-Cieslak]

We've been using new Tree View API to provide structured view of F# projects - in F# project files needs to be ordered according to compilation order so this additional view gives users better information about their project. We also include in the view list of project references, and assembly references so it's really similar to the Visual Studio solution explorer.

It looks like following:

As I've mentioned - ordering of files is really important for the F# projects, and we provide couple of helper commands to manage it (move file up/down etc). Those commands work more or less, but I don't think it's best UX. I think it would be super nice if users had ability to use normal drag and drop to manipulate the order - just as they are able to manipulate files in normal file explorer (drag and drop files to move them to subfolder for example)

[cartermp]

Just to add weight to this: file ordering is critically important for F# users. We're also exploring adding click and drag for CPS in Visual Studio, which would leave VSCode as the only F# editor that doesn't support click and drag for file ordering.

[forki]

Oh that would be an awesome feature!

[mastoj]

💯 * 👍

[hakonrossebo]

+1

[DmitryBatalov]

+1

[priort]

That would be a really helpful feature.

[priort]

+1

[magnushammar]

This would be awesome. Some things are actually better done with a GUI and this is one.

[pirrmann]

+1

[Neftedollar]

F# developers need this feature as an air.

[MangelMaxime]

💯

[schaveyt]

+1

[DanTup]

I'd like to see this too for a UI tree we're building. Some things it'd be nice for the API to support:

• Declaring if a node is draggable or not
• Ability to drop on top of or in between items (re-order versus changing parent)
• Ability to provide feedback while dragging about whether a given location is valid to drop on

[FrederickBrier]

Someone wrote that we need to wait for the vscode team to implement the feature. Does that mean that we should not fork the repo and try to implement it? Because that that is not their process and a pull request would be rejected? Thank you.

[zhaoyi0113]

any update about this requirement?

[sandy081]

No plans yet.

[e-stets]

Is this still considered? It would be a great addition to simplify a lot of UI workarounds for TreeViews.

[justinfagnani]

Relatedly, it would also be great to enable dragging from a tree view into an editor, especially a custom editor. This would enable tree views to provide snippets, components, colors, etc.

[barbaravaldez]

Are there any plans for implementing this in the near future?

[sirfuzzalot]

+1

This issue has been sitting on the backlog for three years now and in the meantime the Tree View API has grown and matured some, but we're still missing this key feature set. Users frequently compare the drag and drop capabilities they have inside of the Explorer/Folders view to what they are experiencing in the extension views. Would love to see this request get some traction!

[LighghtEeloo]

Another vote for this feature! A same logic with explorer will boost extension experience.

[gplumb]

This request was created in 2017! Come on... clearly people want this feature - what is it going to take to get this work into a sprint??

[worksofliam]

Also would be nice to have

[benedyktdryl]

@alexr00 @sandy081 is there any exact reason or obvious blocker to avoid start working on that feature? Is there any chance I can contribute to VSC to start any work in that area? Do you have any discussion group so you can share with me your vision about this feature? I will be more than happy to start working on it.

[alexr00]

@benedyktdryl thanks for offering to make a PR for this feature. It is, however, a large feature and likely not a good candidate for a PR.

You can check out our roadmap for features that we have prioritized: https://github.com/microsoft/vscode/wiki/Roadmap

We do plan on investing more time in extension tree views, and this feature request will likely be part of that.

[TestUser013]

Hi, Since there is no way to use Drag&Drop functionality I would like to add buttons to move Tree View items up and down. Is there any way to change the order of tree list items from plugin?

[gplumb]

You could do that via some commands in your view and a custom tree data provider (https://code.visualstudio.com/api/extension-guides/tree-view).

Drag and drop would be much easier though ;-)

On Thu, 11 Mar 2021, 09:19 TestUser013, @.***> wrote:

Hi, Since there is no way to use Drag&Drop functionality I would like to add buttons to move Tree View items up and down. Is there any way to change the order of tree list items from plugin?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/32592#issuecomment-796592510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFU7ZQ3UOJNC73GXH5AIZDTDCDLRANCNFSM4DXAOV5A .

[LinkShen]

Mark. Look forward any new progress. I am making an extension used to organize source tree need this.

[alexr00]

We discussed this API:

https://github.com/microsoft/vscode/blob/39d180d6624d0471b9617d69d74f89da3345cf06/src/vs/vscode.proposed.d.ts#L884-L904

Problems with this approach:

• It is tree view specific.
• It doesn't allow reordering.
• It doesn't let us support drag feedback or other drag properties in the future.

Instead, we could add a DragAndDropController (final name TBD) to the TreeView:

    export interface TreeView<T> extends Disposable {

        readonly dragAndDropController: DragAndDropController<T>;
    }

    export interface DragAndDropController<T> extends Disposable {
        /**
         * Extensions should fire `TreeDataProvider.onDidChangeTreeData` for any elements that need to be refreshed.
         *
         * @param source
         * @param target
         */
        onDrop(source: T[], target: T): Thenable<void>;
    }

With the dragAndDropController we would not need the canDragAndDrop property on the TreeViewOptions.

This would give us the flexibility to expand the API to include other common drag and drop options later.

Additionally, we should consider updating TreeDataProvider.onDidChangeTreeData to allow firing with an array,

[gplumb]

Great to see this being discussed :-)

I would like to suggest an addition to the DragAndDropController interface in TreeView:

export interface DragAndDropController<T> extends Disposable {
/**
* Extensions should fire `TreeDataProvider.onDidChangeTreeData` for any
elements that need to be refreshed.
*
* @param source
* @param target
*/
onDrop(source: T[], target: T): Thenable<void>;

        /**
         * Evaluate whether a given drag and drop operation is allowed.
         *
         * If false, VS Code will render a cursor equivalent to
"cursor:no-drop;", preventing onDrop()
         * from firing when a drag operation terminates
*
* @param source
* @param target
         * @returns boolean
*/
canDrop(source: T[], target: T): Thenable<boolean>;
    }

This would give authors so much more flexibility. For example, level '0' in a tree might represent a container of some sort, who's children can be freely ordered within it, but cannot be moved to a different parent (a contrived example on the face of it, but a use case I have in a simple user interface editing extension, where such constraints exist).

Would love to hear your thoughts on this!

Thanks

G

[justinmk3]

Will this allow custom treeviews to receive drops from other sources, e.g.

• vscode editor tabs
• vscode file explorer
• the OS file explorer (e.g. macOS finder)

[alexr00]

We're only working on supporting drop from the same tree view. If the tree item is backed by a resource/file then drag-out into other places should have some support.

[alexr00]

Some thoughts on where we might go:

https://github.com/microsoft/vscode/blob/45784932359f3d1d9a59f7bdcfa988f5053eee62/src/vs/vscode.proposed.d.ts#L916-L937

[alexr00]

Other possible drag events, for reference: https://developer.mozilla.org/en-US/docs/Web/API/Document/drop_event#see_also

The HTML spec's DataTransfer: https://html.spec.whatwg.org/multipage/dnd.html#datatransfer

[idoprz]

Will this allow custom treeviews to receive drops from other sources, e.g.

• vscode editor tabs
• vscode file explorer
• the OS file explorer (e.g. macOS finder)

Support of droping into editors tabs (custom editors) can be very helpfull for some scenarios. Also, supporting drag from webview panels can be great!

[alexr00]

The current proposal sets us up for enabling many other drops into tree views. It would enable some drags into places like editors, but not all. It will not support any drag from webview panels.

https://github.com/microsoft/vscode/blob/8f774f132e036347c018b9cc69c79a178322dacb/src/vs/vscode.proposed.d.ts#L916-L942

[gplumb]

I like this approach :-)

How come this isn't planned for the webview? Selfishly, it'd light up a few useful scenarios for my extension!

G

On Mon, 19 Jul 2021, 10:00 Alex Ross, @.***> wrote:

The current proposal sets us up for enabling many other drops into tree views. It would enable some drags into places like editors, but not all. It will not support any drag from webview panels.

https://github.com/microsoft/vscode/blob/8f774f132e036347c018b9cc69c79a178322dacb/src/vs/vscode.proposed.d.ts#L916-L942

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/32592#issuecomment-882375640, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFU7ZQ7R6YEQDJEYARQW4LTYPSUDANCNFSM4DXAOV5A .

[pwsses]

+1

[abflow]

We would find useful to drag from custom tree views into webview panels and from webview panels into custom tree views.

[FrankBlabu]

We would find useful to drag from custom tree views into webview panels and from webview panels into custom tree views.

Even more, could a more general drag/drop interface make sense here ? My use case is that: Drag some graphically represented element from another application via mouse. Drop it into the VSCode text editor (python mode, in that case). The VSCode extension now handles this MIME based dropped element and insert a text representation of it just into the editor at the drop position. So this is basically some sort of drag/drop based snippet handling with external sources.

There seems to be some existing code pointing into that direction in src/vs/editor/contrib/dnd/dnd.ts:DragAndDropController which relies on the undocumented/private (?) 'registerEditorContribution ()' function. A general, documented way to achieve that would be helpful.

[nickzhums]

To provide some additional info from VS Code Java team. We've been hearing feedback that developers want this kind of drag and drop feedback from our past survey and customer development.

In addition, some of the community videos have mentioned about this feature request as well (https://www.youtube.com/watch?v=uq4GjRF_860&ab_channel=JavaBrains) - 33:20 (Video itself has 78K views)

Would be great if we can support drag and drop in tree view soon and make this higher priority - thanks!

[nickzhums]

Hello folks, just wondering what the current plan for this feature is ? We have customer feedback that they find this missing in the Java Project Explorer and think it is inconvenient - thanks!

[gplumb]

Hi all! Would be good to know if this made the cut from last year's roadmap or not :-)

On Fri, 14 Jan 2022 at 06:45, nickzhums @.***> wrote:

Hello folks, just wondering what the current plan for this feature is ? thanks!

— Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/32592#issuecomment-1012816637, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFU7ZU6X6UGDM4QH7EQPXDUV7BAXANCNFSM4DXAOV5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[gjsjohnmurray]

Would be good to know if this made the cut from last year's roadmap or not :-)

It was on the current iteration plan (#139607) until 10 days ago, then removed by @kieferrm (not moved into the Deferred section though). But there's evidence of work on it by @alexr00 recently, so I think it stands a chance of landing in 2022.

[alexr00]

@gjsjohnmurray is correct, it does stand a chance of landing in 2022. We're just going through our API process and refining it now.

Folks who are interested in it can try out the current API proposal and provide feedback in this issue if you want to help!