Docker Desktop 4.9 preserves the container table while you work

A container list becomes less useful when it hides the names needed to distinguish its rows. Docker Desktop 4.9 addresses that problem through resizable columns and retained table state. The June 2 release notes describe a redesigned containers table with bulk deletion and a button for copying a container ID. These changes improve the connection between what the dashboard displays and what an engineer needs to operate on.

Docker's release announcement explains the intended workflow. Resizing a column exposes complete container and image names. Sorting and search results survive navigating away from the tab and returning. The interface can therefore retain the view used to investigate an application while the engineer looks elsewhere in Desktop.

I prefer Docker workflows built around explicit image definitions. A graphical container list still has a practical role alongside those files. It should make the currently running result easy to identify without obscuring which image or container an action refers to.

Retaining a view preserves useful context

Table state affects more than appearance. An engineer can narrow a list, inspect another part of the application and return to the same results. Without that persistence, every transition requires reconstructing the previous view. The relevant information may still exist, but the user has to repeat the work needed to find it.

The notes explicitly include persistent sorting and resizing. The announcement also describes retained search results during tab navigation. These properties give the interface a more stable relationship with an ongoing task. A column widened to reveal a complete name can remain useful after another screen temporarily takes focus.

Bulk removal applies the same idea to cleanup. Multi-select checkboxes let the user identify a set of containers before removing them together. The set remains an explicit selection in the table. This supports a common local development operation without requiring repeated row-by-row actions.

The container ID copy button also connects the dashboard with terminal work. Display and command interfaces do not have to be competing ways of managing an environment. Copying the identity of the object being inspected provides a direct handoff between them. The release notes specify a container ID, which is the relevant identity when the next operation concerns that container.

The footer describes Desktop's environment

The redesigned dashboard footer displays the Desktop version and virtual machine CPU and memory usage, according to the announcement. These values describe the environment managed by Desktop. Their location makes them available while the user works elsewhere in the dashboard.

That distinction matters when interpreting resource use. A value for the VM is not automatically a measurement of a single application container. The footer supplies an overview of Desktop's environment, while an investigation of a particular workload needs information with the corresponding scope. Keeping the VM identity visible helps prevent an imprecise description of what a displayed number means.

Version visibility has a similar purpose. A screenshot or support conversation can identify the installed package without relying on a remembered update history. I regard that as useful context because the same application image can run under different Desktop builds. Naming the package makes a report about its interface or integration more specific.

A WSL mount fix concerns the identity of a path

The maintenance notes include a Windows fix with a precise trigger. A file or directory is bind-mounted into a container. After the container exits, the host object is replaced by the other type under the same name. Previously, later attempts to bind-mount the new object failed.

This distinguishes a path's spelling from the filesystem object currently found there. The directory name can remain unchanged while the thing it names changes from a file into a directory. The integration must recognize the replacement when preparing a later mount. An earlier successful mount does not establish that the object at that path will remain the same type forever.

The fix is relevant to local workflows that replace generated paths or reorganize source directories between runs. That relevance follows from the documented trigger, without assuming a particular application caused it. The useful explanation is the sequence of mounting, container exit and replacement, because it separates this failure from a general claim that bind mounts do not work on WSL.

Guides and integration fixes remain part of the package

Desktop's homepage adds guides for several common services, including MySQL and RabbitMQ. The release also fixes the Extensions Marketplace ignoring configured HTTP proxies. A user behind a proxy can therefore encounter a different outcome even though the container engine is unchanged by that particular fix.

The bundled components also advance, including Compose 2.6.0 and Engine 20.10.16. These versions identify the package contents, but the dashboard changes have their own purpose. They preserve the engineer's selected view and expose the identity needed for the next operation. Alongside the WSL fix, they improve the correspondence between the resource a user sees and the resource Desktop actually manages.