When I launch graphical applications from the container, they use a light theme. How can I enable dark theme for applications launched from the container?
They don’t have to look exactly like host’s applications, although I am considering that as well.
You must set it inside the container.
With your setup, the container is just using the host’s xserver, but everything else (programs, config files etc.) is inside the container itself.
So you might be able to:
turn dark mode on in your container os (ubuntu)
set dark mode for specific applications
set dark mode for specific toolkits etc. like Qt for example
I’ve tried changing the theme-related configuration in several (but not all, I guess) ways within the container, but often nothing has changed (except per application settings via env).
I copied some files of the theme installed on the host and noticed this: if the container contains the files of the theme currently activated on the host - it is automatically applied to the windows launched from the container. Without having to apply any configuration in the container.
I wondered how it works. Does the container get some of the related parameters via shared X11?
It would be useful to have an idea of ​​what exactly the container knows about the host depending on the profiles applied (or some other configurations?). I think this would help me to independently solve some of the problems I still have related to GUI apps inside containers.
Could you please tell me where to start digging for this information?
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.
I would not have thought that snap applications also went this path of “problems”.
I just started looking for information on why many graphical applications throw out warnings about problems related to the D-Bus…
The security side is not an issue for me, but reducing problems with graphical applications launched from a container has a higher priority, while maintaining a certain level of isolation.