Ability to know if a custom view is visible or not

[patrys]

I maintain an extension that tries to have a tree view follow the cursor position in file in a similar fashion to how explorer pane follows the currently open document.

However when the tree view is collapsed or when a different sidebar pane is active VS Code will forcefully switch to the Explorer pane and expand the tree view. Users find it highly annoying, especially when trying to follow a stack trace in the debugger as clicking any stack frame focuses the code editor which in turn activates the extension and switched away from the Debugger to the Explorer pane.

The only option accepted by TreeView.reveal is select. I'd like to propose a focus option that controls whether the view should be brought to the front (ie. pane focused and tree view expanded) if it isn't there already.

[sandy081]

I do not think focus will solve your problem. In fact it might worse. Because currently focus remains in the editor, with focus option you can control if to focus the view or not.

I think what you need to know is if the view is shown or not. Reveal it only if view is shown. Is it correct?

[patrys]

reveal() will currently make the view visible if it isn't. This means switch away from whatever the user was doing at the moment which is not always wanted.

[sandy081]

Yes, reveal API as documented is to show the element to the user. So it is expected. But as I said you would like to decide when to call this or not.

[patrys]

I guess you could say so. My extension has no way to tell whether the view is currently visible or not. I want it to work the same way the explorer file tree does (ie. change selected element without forcing the explorer pane or the file tree view to be presented).

[sandy081]

Yes, I agree that currently an extension cannot know if a view is visible or not. I would assume if you have that knowledge then this will fix your issue?

[patrys]

It would, yes.

[DanTup]

If we're going to skip selecting items when the view isn't visible, do we have the right events to ensure we can select the required item when the tree becomes shown? If not, would it be better to still allow us to select without making the view visible?

[sandy081]

@DanTup This will let you know if the view is visible or not and then allow you to call reveal. I think it makes sense to have an event when a view is visible

[DanTup]

Yeah, without the event, when the user first switches to the outline, it won't have any selection. It may need to fire after the tree has been rendered to ensure the nodes are all there so we can select?

[Gama11]

This behavior actually makes the reveal() API unsuitable to re-implement something along the lines of "explorer.autoReveal" in its current state. Imagine being in the search viewlet, and switching tabs forcefully changes back to the explorer viewlet to "reveal the file". Similar for forcefully reopening collapsed tree views. I can see how it might be useful that you can do this, but in most cases it's probably not desirable. :)

(for context: I originally suggested the API for that "re-implement explorer.autoReveal use case" in #30288)

[DanTup]

@sandy081 I'm guessing it's not likely this would be done for v1.24? (not bumping, just trying to schedule merging a preview of something).

[sandy081]

Mostly for 1.25

[DanTup]

Ok, thanks!

[sandy081]

Tree view has now visible property and an event to listen on it.

/**
 * Event that is fired when the [selection](#TreeView.selection) has changed
 */
readonly onDidChangeSelection: Event<TreeViewSelectionChangeEvent<T>>;

/**
 * `true` if the [tree view](#TreeView) is visible otherwise `false`.
 */
readonly visible: boolean;

/**
 * The event that is fired when there is a change in [tree view's visibility](#TreeView.visible)
 */
export interface TreeViewVisibilityChangeEvent {

	/**
	 * `true` if the [tree view](#TreeView) is visible otherwise `false`.
	 */
	readonly visible: boolean;

}