Vscode: TreeDataProvider: allow single click and double click to work the same way they do in the file exporer

[dkdaddy]

I can add a command to activate when an item is selected, but I want the same behavior as the in-built explorer where single click opens the tab with the file (title in italics) and double click opens it permanently as a new tab.

Can this be added to the TreeDataProvider interface?

[eamodio]

@sandy081 A similar issue: https://github.com/microsoft/vscode/issues/39601 was closed, but I would love to revisit this. As this behavior (single click to open a preview and double to pin it) is IMO an expected behavior by our users -- as the file explorer, SCM, search, all provide this behavior.

[dkdaddy]

ahh sorry, I only searched the open issues, not the closed one.

[vscodebot[bot]]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodebot[bot]]

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[bpasero]

@alexr00 would be great if we can put this on the radar, given https://github.com/microsoft/vscode/issues/109779 which is based on feedback we got from users.

The current logic is to execute the item's command:

https://github.com/microsoft/vscode/blob/6b413891c578868409788df9c096e920a3c17476/src/vs/workbench/contrib/views/browser/treeView.ts#L452

@eamodio you seem to have a similar case as well here:

https://github.com/microsoft/vscode/blob/ff805b3a35683eed66f5491064b0a4e744f83d43/src/vs/workbench/contrib/timeline/browser/timelinePane.ts#L908-L908

I wonder if we should simply pass over the editor options to the command? That is very subtle though and extensions would probably forget to adopt this.

//cc @jrieken for https://github.com/microsoft/vscode/issues/101522

[alexr00]

@bpasero this issue is about adding API for the tree for double click. It is up to the user what command they want to execute.

[bpasero]

@alexr00 I am not sure I would agree, from the OP:

I can add a command to activate when an item is selected, but I want the same behavior as the in-built explorer where single click opens the tab with the file (title in italics) and double click opens it permanently as a new tab.

There are more conditions under which an editor opens as non-preview:

• keyboard (e.g. explicit Enter)
• mouse-middle-click
• double click

@dkdaddy fyi maybe you could clarify the request is about preview/non-preview behaviour and not so much about double click?

[alexr00]

In order for extension authors to add a command to execute on double click, we first need to add double click to the API. Then they can use whatever command they want on double click, including a command (if it exists) that opens a file in non-preview.

[alexr00]

Ok, now I understand what you're saying. After discussion, our proposal is not to change the API surface but instead to always append an additional parameter to the command and document it:

                /**
         * The [command](#Command) that should be executed when the tree item is selected.
                 * NEW: The last [arg](#Command#args) for tree items that are resources will be the 
                 * `options` for `vscode.open` as described in the [documentation](https://code.visualstudio.com/api/references/commands). This is intended to provide extensions with an
                 * easy way to follow VS Codes default or set open options.
         */
        command?: Command;

[bpasero]

@joaomoreno reminded me that the SCM changes view should also benefit from our solution.

[jrieken]

What has been discussed so far

1. Add the open-options as last arguments (https://github.com/microsoft/vscode/issues/85636#issuecomment-721137634) when calling the tree command.
   👍 simple
   👎 adoption required
   👎 breaks existing extensions that already use the notion of a last argument (e.g gitlens)
2. The UI does the right thing when tree command calls vscode.open during its execution
   👍 no adoption
   👎 too much magic, not a silver bullet?
3. Extensions that use the vscode.open-command as their tree command get the special treatment
   👍 simple
   👎 adoption required
   👎 extension needs to eagerly compute arguments for the open command, e.g the line a reference needs to select/reveal. Extensions like gitlens cannot do that eagerly and we would need more API to "resolve" a tree item before running its command

[bpasero]

API call input for discussion:

// ######## A: registerTreeViewCommand ##########

export function registerTreeViewCommand(command: string, callback: (treeView: TreeView<any>, options: TextDocumentShowOptions, ...args: any[]) => void, thisArg?: any): Disposable;


// ######## B: registerOpenableCommand ##########

export function registerOpenableCommand(command: string, callback: (options: TextDocumentShowOptions, ...args: any[]) => void, thisArg?: any): Disposable;

// Maybe more generic with an extra interface OpenableContext to be able to add more in the future?


// ######### C: TreeContextAwareCommand ############

export interface TreeContextAwareCommand {
    command: Command; // will get TextDocumentShowOptions pass in as argument
}

export class TreeItemVariantA {
    command?: Command | TreeContextAwareCommand;
}


// ######### D: vscode.open ############

export class TreeItemVariantB {
    command?: Command | 'vscode.open'; // will take the `resourceUri` if provided and pass TextDocmentShowOptions accordingly
}


// ######### E: Event on Item ############

export interface TreeItemDidOpenEvent {
    options: TextDocumentShowOptions;
}

export class TreeItemVariantC extends TreeItem {
    onDidOpen: Event<TreeItemDidOpenEvent>;
}


// ######## F: Event on TreeView ##########

export interface TreeViewDidOpenEvent {
    item: TreeItem;
    options: TextDocumentShowOptions;
}

export interface TreeView2<T> extends TreeView<T> {
    onDidOpen: Event<string>;
}


// ######## G: Arguments/Proxy Trick Hack ##########

const treeItem: TreeItem = {
    command: {
        command: 'my.open',
        title: 'Open',
        arguments: [treeItemUri, <some tree proxy static that returns TextDocumentShowOptions?>]
    }
}

//#endregion

[bpasero]

API call results: we will update the documentation in the API that vscode.open and vscode.diff are the preferred commands to use for a custom tree item. When they are used, we will make sure to pass in the correct TextDocumentShowOptions based on the way how the tree item was clicked. We will validate this approach by adopting it for our built in extensions such as @jrieken 's references view.

[jrieken]

I have pushed changes to the references viewlet to make it use vscode.open with arguments. That should allow to go forward on this. However, this _currently_ uses preserveFocus: true to preserve the existing behaviour. My expectation is that this won't be needed anymore once the tree does its magic.

[bpasero]

I tried to adopt this but failed, because commands on the main side are generated:

My wip changes are in https://github.com/microsoft/vscode/commit/fd968feeea7e0136278d915fbcdc3503fe6aadf0 that naively assumed that vscode.open is the command in use.

I need some help to know how to proceed as I have not a lot of knowledge in this commands area on the ext host.

[joaomoreno]

I really like this solution that whenever using vscode.open, the open args will be passed around automatically. 👏

I'd love if we generalize it for contributable commands to behave just like vscode.open: there should be a way for them to also demand open args to be passed when invoked from a list/tree. That way we can further fix git and gitlens.

[bpasero]

I need some feedback in https://github.com/microsoft/vscode/pull/110398

[jrieken]

One additional idea that shouldn't get lost is a special argument for open-commands that allows lazy resolving. That's an alternative to resolveTreeItem and would also work for SCM and the timeline. Like a promise or a callback returning a promise that will resolve to the actual arguments.

I have also created https://github.com/microsoft/vscode/issues/110459 which explores ideas to make the API commands more visible to our tooling. ➡️ TypeScript brains welcome!

[bpasero]

@jrieken I think you can remove your handling of preserveFocus now. I pushed my changes.

As extension author: use vscode.open or vscode.diff commands for your TreeItem to get the same treatment as built-in views have.