Plots.jl in a docker container

I am trying to use Plots.jl in a docker container (FROM julia:1.9.4-bookworm).

I think I am able to create the plots, but I get various warnings and errors from qt.

Examples include:

qt.core.plugin.factoryloader: Got keys from plugin meta data QList("vkkhrdisplay")
qt.core.plugin.factoryloader: checking directory path "/.julia/artifacts/7f59a0ec3d19c98dce30a3ba8ea9cbd8824ce4a6/bin/platforms" ...
qt.core.library: "/.julia/artifacts/466e859891e85a1f8a887e712f17b1645ec9c803/plugins/platforms/libqxcb.so" loaded library
qt.core.library: "libdbus-1" loaded library
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: vnc, eglfs, xcb, offscreen, minimal, linuxfb, minimalegl, vkkhrdisplay.

Aborted (core dumped)
connect: Connection refused
GKS: can't connect to GKS socket application

GKS: Open failed in routine OPEN_WS
GKS: GKS not in proper state. GKS must be either in the state WSOP or WSAC in routine ACTIVATE_WS

Here is a workflow (of an MWE I created) with the corresponding logs:

Does anybody know how to fix this?
In essence I only need a lightweight plotting package. For now I would like to create a pie plot. I know there are various plotting packages. If you can recommend an alternative which does not need Qt and works on a headless server , I am all ears.

Is this any help?

Deactivate plot display to avoid need for X server - Specific Domains / Visualization - Julia Programming Language (julialang.org)

2 Likes

Yes. Thank you !

at the start of my julia script I just added:
ENV["GKSwstype"]="nul"

Veering offtopic… I first programmed using GKS graphics at CERN in the 1980s… I guess it still underlies many graphics front ends.

Ed: @johnh ? Veering offtopic?

Yes, that’s probably true. I wrote one of the first GKS implementations in the 80s (now part of GR) that ran on personal computers and mainframes. All the C and Fortran programs that our scientists wrote decades ago based on GKS still run today (without any changes). I would often wish the same for modern software. My conclusion: “Old” software doesn’t always have to be bad - as long as it is maintained. :wink:

1 Like