A container is a process tree (a hierarchy of running processes) that is isolated from the rest of the system. LXD allows us to pierce this isolation. For GUI apps, we expose the host’s X server Unix socket to the container, so that an application in the container can get GUI output on the host. On the modern Linux desktop, a GUI application requires more facility from the desktop environment.
For example, GUI applications use D-Bus to communicate with the rest of the system. The instructions do not show how to present the D-Bus socket of the host to the container (
/var/run/dbus/system_bus_socket). By running the same app on the host and in the container, and using tools like
strace, you can start identifying and plugging any missing bits and pieces. In the end, it is well possible to recreate the full desktop environment of the host in the container.
Note that a GUI application running in a container is similar to a GUI application in a snap package. You would be recreating the snap package features that make it possible for a snap package GUI application to run, and be almost indistinguishable from running on the host.
A couple of years back, many snap packages of GUI applications looked terrible as they were using the default theming. This issue has been resolved (exposing the theme files of the host to the container, since a snap package cannot know all themes). In terms of LXD containers, you would likely bind-mount the themes/ directory.