@octref only the compositeBar inside the panel has that knowledge, try getting it from there.
Nothing for endgame -> march

I also wanted to suggest having Ctrl-Tab and Ctrl-Shift-Tab bound to them using panelFocus. But it seems we don't have that when condition and have to do terminal/output/problems/debug-console focus. But when I look even closer there seems to be no output focus or debug-console focus...

Just want to know if you are pro or against adding those two shortcuts behind the when clause and if I should look deeper into this.

Against since it will break muscle memory of users. Currently ctrl-tab changes the editor no matter the focus. I would not just change this.

@isidorn How about cmd + ] and [? They are bound to indentLine or outdentLine by default on editorTextFocus. I'm thinking about making them go to next/prev Viewlet or Panel Item when Sidebar or Panel has focus.

@octref let's start without a default shortcut and if we see that this action is popular we can easily add one later. This is a better strategy than adding first since it is later hard to remove

@isidorn I'm not sure if I understood your suggested approach, but this seems to work fine.

@octref thanks for your PR. However this week we are in endgame and on Thu I go on vacation so I will review this next milestone. Hope that makes sense.

Sure, see you next month :)

@octref thanks again for your PR. However I find it strange that we add next / previous panel and we do not add next / previous viewlet.
How does this go together with the Views > Open View action.
From the implementation perspecitve everything looks great. Except that I would try to do more code reuese between the two actions. Since they are doing everything the same just the +1 or -1 on to which panel to navigate.

fyi @sandy081 since he is tackling various views this milestone

@isidorn

However I find it strange that we add next / previous panel and we do not add next / previous viewlet.

I think it's better to do that as another PR. I can do it too.

How does this go together with the Views > Open View action.

I never used it. I believe that action serves a different purpose than this one. Ideally in each group (editor, viewlets, panels) I just want an action to go to the prev/next thing visually, not to recall names of each parts of VS Code and jump to it.

What I asked for in #15262 (UI part aside) is contextual ctrl+tab. Ideally I hope we can have these commands / when clauses

Ctrl-Shift-Tab:

• workbench.action.previousPanelItem when panelFocus
• workbench.action.previousViewlet when viewletFocus (or sidebarFocus)
• workbench.action.previousEditor when editorFocus

Ctrl-Tab:

• workbench.action.nextPanelItem when panelFocus
• workbench.action.nextViewlet when viewletFocus (or sidebarFocus)
• workbench.action.nextEditor when editorFocus

Except that I would try to do more code reuese between the two actions.

I addressed that.

@octref thanks. The PR looks good to me know. And these actions make sense.
Let's see what @bpasero and @sandy081 think about introducing these actions and if they are ok we can merge it in.

I think having similar action to navigate viewlets is good. How about navigating views inside viewlet?

@isidorn if you want to merge for April, feel free to review. otherwise running out of time, moving to May.

@bpasero I reviewed this and the code is good. I just need your blessing to add the "Next Panel" / "Previosu Panel" actions. You do not have to look at the code

@isidorn oh OK. We can have the actions but I am with @sandy081 and think for consistency we could have the same actions for viewlets as well. I am not sure about navigating within viewlets to other views, for that you could probably just "Tab".

@octref I think commands like "Previous Panel item" should user uppercase all the way (e.g. Previous Panel Item)

@bpasero great, thanks for feedback
@octref then this PR is good, just update the label and once you provide the viewlet actions PR I will merge both these things in. In the meantime let's keep this on deck.

@isidorn @bpasero I've cleaned up the API a bit, including

• getOrderedPanels(): string[] -> getPinnedPanels(): IPanelIdentifier[] to follow more of our terminology and align with getPanels
• Clarified a bit on that getPanels return panels following the visual order

I have a question though. In compositeBar.ts, now we have this:

	private getVisibleComposites(): string[] {
		return Object.keys(this.compositeIdToActions);
	}

	public getPinnedComposites() {
		return this.pinnedComposites;
	}

They seem to be doing the same thing.

• Why is getVisibleComposites using Object.keys(this.compositeIdToActions) instead of pinnedComposites? Are those two different in some scenarios?
• Can I remove getPinnedComposites and make getVisibleComposites public?

@octref sorry for not responding I was on vacation when you asked the question.
And now @sandy081 has refactored the whole rold of the compositeBar so you would have to check with him.
So for us to continue here can you please resolve conflicts possible with the help of Sandeep and once we have taht we can merge that in if @sandy081 agrees

A lot has changed on master.. I'll open a new PR.