Support for multiple selection of items and actions on these items (batch)

[wlsc]

It would be very helpful, if one would have an opportunity to select multiple, for instance, containers and then remove or stop containers with just one click. Current behavior: one is forced to select and remove/stop containers one by one.

[StephenWeatherford]

Not sure this is possible in the views, need to find out.

[StephenWeatherford]

@wlsc FYI, if you select "Stop Container" from the Containers node directly, there is an "All Containers" option. Does that suffice for you?

If not and view can't do it in the view, we could consider using a checklist when people do this from Containers node.

[wlsc]

@StephenWeatherford thanks for your reply. I have a use case where I do need to stop/remove 3-4 containers from 9 in total. Unfortunately, I do not want to stop or remove them all.

[ejizba]

@wlsc it's been a while - but I believe this was fixed for you in #966. If you run "Stop Container" from the command palette, you will see something like this:

You can try out the latest from master with these instructions: https://aka.ms/azcodeInsiders

The only reason I didn't close this yet is we still don't allow users to multi-select directly in the tree. Not sure how necessary that part of the feature is.

[eine]

A possible intermediate solution is to add a 'Action'/'Do' button in the CONTAINERS title, on the left of 'Prune'. It would be a dropdown with 'stop', 'remove', etc. Each of the items would point to the corresponding 'Docker Containers: ...' command.

[ejizba]

Multi-select support for custom trees in VS Code is being tracked here: microsoft/vscode#76941

@1138-4eb It's in the "August 2019" milestone so I guess I'd prefer to just wait for that

[bwateratmsft]

One quirk that I've found while investigating proper multi-select relates to commands which are conditionally shown (for example, the "Stop" command is not shown for already-stopped containers, likewise "Start" for already-running containers).

If you select multiple items, and right-click one of them, the one you right click decides which commands are shown. For example, if I multi-select a stopped and a running container, and right click on the stopped one, I'll see "Start" (and more); whereas if I select those two and right click the running one, I'll see "Stop" (and more).

I think this is probably not a serious issue since most of the time people will select items for which an action would be valid on all (i.e. they probably won't try selecting a stopped and a running container, and doing "Start"). Nonetheless we do need to investigate what will happen if I request an invalid action, and potentially have code ignore it where it isn't valid.

[bwateratmsft]

@eine alludes to this in #1494. Certain commands are currently implemented as single only, I'd like to hear what people think--whether it even makes sense to turn them into multi-select capable. All those commands which are currently multi-capable via the command palette, IMO should become multi-capable via context menu. For containers this includes stop/start/restart, and for all it includes remove.

• Containers
  • Single only:
    • Attach Shell
    • Attach VSCode (from Remote - Containers extension)
    • Open in Browser
    • Inspect
    • View Logs
  • Multi (right now, only via command palette):
    • Remove
    • Restart
    • Start
    • Stop
• Images
  • Single only:
    • Copy full tag
    • Inspect
    • Push
    • Run
    • Run interactive
    • Tag
  • Multi (right now, only via command palette):
    • Remove
• Registries
  • Single only:
    • (All of them)
• Networks
  • Single only:
    • Inspect
  • Multi (right now, only via command palette):
    • Remove
• Volumes
  • Single only:
    • Inspect
  • Multi (right now, only via command palette):
    • Remove

@wlsc @eine @TiemenSch @wintercreative, also @BigMorty @EricJizbaMSFT @StephenWeatherford @karolz-ms : what do you guys think? Are there any that are currently single-only that you feel should be multi-capable?

Here are my thoughts:

• I could go either way on "Inspect" supporting multi (and thus opening a tab for each). Same for View Logs on containers. Anybody feel strongly one way or another?
• I think Registries is complicated enough that we should probably leave it as single-select only

[philliphoff]

@bwateratmsft I think you've got the right matrix for single/multi select support. I'd stick with "single" for inspection and logs commands, at least until we see a real need/desire for multi-select. I also agree that the registries tree view is complicated enough to leave single-select for now; if there's a need for multi-select for certain nodes (e.g. pull of Docker Hub images), we can consider that later.

[karolz-ms]

Agreed with the general approach; I think we are at a good starting point.

The multi-select for logs would make sense if we decide to do some sort of integrated log viewer for multiple containers, where you can see logs sorted by time and thus observe interactions between various containers. Until then it makes most sense to stick with single-select for this command.

I would consider multi-select for Images: Run (low pri)

[eine]

Thanks @bwateratmsft! I'm so glad to see this moving forward.

I do think that all the commands that can be harmlessly applied to multiple targets should be enabled/supported. With "harmlessly" I mean when the difference is a matter of using forEach instead of calling a function once only. Open in Browser, Inspect and View Logs should be straighforward to implement. Nevertheless, I believe that Attach Shell and Attach VSCode should work too.

Personally, attaching VSCode to multiple containers (opening an instance in each of 2-3 containers) is a feature that I would use a lot.

I would follow the same pattern for Images, so Inspect, Push, Run, and Run interactive would support multiple targets.

My motivation to suggest this approach is consistency. Having multiple targets supported for some commands but not for others because of arbitrary reasons can be frustrating for users. For Registries, there is a technical motivation (complexity). For others, it feels like some preference/bias. Note this is neither a criticism nor something I have a strong feeling about; but just an observation.

[bwateratmsft]

Attach VSCode would be in the Remote - Containers extension, so it would be up to them to decide if they want to support multi-select.

For the others, I'll create a new GitHub issue so we can gauge the importance for them.

[bwateratmsft]

Attach VSCode would be in the Remote - Containers extension, so it would be up to them to decide if they want to support multi-select.

For the others, I'll create a new GitHub issue so we can gauge the importance for them.

Created #1631.

[BigMorty]

@bwateratmsft your list above looks like a good start. Agree we should consider the others @eine mentions. @karolz-ms had the same idea I did regarding View Logs for multiple containers, having it show in all the logs integrated in time order would be awesome. That said, it would probably be a separate command like "Show Integrated Logs" or something.

[BigMorty]

@bwateratmsft - Should this issue be reopened or are we tracking it with a separate issue?

[bwateratmsft]

@BigMorty I made #1631 for that.

[BigMorty]

Great, thanks!

[bwateratmsft]

Multi-select is now available in Docker extension version 1.0.0.

[wlsc]

big 👍 and thanks to everyone who participated to make this happen! 🎉 🎈 🎈 🎈

[BigMorty]

Thanks @wlsc, the team worked hard on this release and we appreciate your nice comments! 😊