Dear all
(Long introduction) I am trying to integrate gnuplot into our Open OnDemand platform which is offered to our HPC users on our Tier-2 clusters. This app is based on the gnuplot/6.0.1-GCCcore-13.3.0 module, for which you find an EasyBuild recipe on the Easybuild official repo. We use Rocky Linux 8.9 and Intel Skylake architecture.
To launch gnuplot from the Open OnDemand container, I essentially execute the following (inside a noVNC desktop):
export SEND_256_COLORS_TO_REMOTE=1
export XDG_CACHE_HOME="$(mktemp -d)"
eval "$(dbus-launch --sh-syntax 2>/dev/null)" && echo "[INFO] D-Bus launched" || echo "[WARNING] D-Bus unavailable; continue without it"
xsetroot -solid "#D3D3D3" &
GNUPLOT=$EBROOTGNUPLOT/bin/gnuplot
xfce4-terminal \
--show-borders \
--show-menubar \
--show-scrollbar \
-e "bash -c \"GNUTERM=qt $GNUPLOT\""
To keep our container images minimal, xfce is the only graphics environment built into the image.
Now, the problem is when doing the simple plot sin(x), the pop up plot window is frozen, in the sense that it cannot be moved, minimized or closed because of the missing top tray on the window. The same is true when switching to e.g. GNUTERM=x11. As a result of this, the plot window masks the terminal inside the noVNC desktop which is undesirable. What I really like to know is the way to make this window manageable (moving, resizing, closing).
To further the discussion, we also have /usr/bin/gnuplot installed in the image for version 5.2 (patchlevel 4). When I use this pre-compiled binary inside my OnDemand sessions, everything works fine, in the sense that the pop-up plot window can be managed. I wondered whther the version difference could play a role here. So, I installed a similar gnuplot/5.4.2-GCCcore-13.3.0 module for testing purposes, and the problem persists. So, the gnuplot version difference is not the concern here, but perhaps the way it is compiled (by EasyBuild) as a module is.
Now, my question is: Is there any compilation flag that can enable managing the pop up plot window? Do you have any other tips here?
Kind regards
Ehsan (VSC, KU Leuven)
You are describing a multi-layered environment that I have no experience with, so I can only offer some general suggestions or pointers. As you probably know, the lack of a frame for the plot window is due to the window manager (or lack of one). You mention xfce is available, but is it actually running? If so, why is it not providing a frame for the window? Moving/resizing/closing/raise/lower is also controlled by the window manager. However, the gnuplot plot windows for both x11 and qt should close in response to hot-keys "q" or "ctrl-q". If this is not the case then it could be that neither the keyboard or the mouse is being given focus so that the plot window receives hot-key or mousing events it can respond to.
It may be relevant that for both the x11 and qt terminals gnuplot splits into two separate processes - one running "gnuplot" and a separate process ("gnuplot_qt" or "gnuplot_x11") responsible for managing the plot window. This pair of processes communicate via pipes. Could it be that your environment is giving focus to the wrong one of these two processes? Or could it be that the pipes are not being set up properly, or are being blocked somehow?
It might be informative to using gnuplot with "set term wxt" instead, since that terminal runs out of the main gnuplot process rather than spawning off a separate process to manage the plot window. Unfortunately I see that the build recipe you link to explicitly disables the wxt terminal.
A desperation fall-back might be to use the kitty terminal "set term kitty", which will draw the graphics in the same window used for your command entry. This would give give you all the normal plot commands, but interaction with the plot is possible only via the arrow keys and hot-keys rather than the mouse. This would require support for the kitty graphics protocol in the terminal emulator that gnuplot is running in.
An even more desperation fall-back would use the sixel terminal "set term sixel". This one acts more or less like the kitty terminal but requires sixel support in the terminal rather than kitty. sixel is more limited in a number of ways, in particular color use.
Dear Ethan
Thanks for your extended response. As a matter of fact, the pointer on switching to the
wxtterminal could at least solve part of the problem. I built a custom gnuplot v6.0.2 coupled withwxWidgetsmodule, and the resulting plot window can be only moved, but not minimized or closed. So, this is already some partial progress.Any more remarks on being able to control/customize the plot window under
wxt?By the way, the 'q' hotkey works fine to quit the plot window.
The other fallbacks (i.e. kitty and sixel) were not much of success, because I do not get any plotting pop up window from either of them. So, we can perhaps try to focus on the
wxtterminal and hopefully improve the situation, if possible.I am pretty sure your problem is not with gnuplot per se, but with the lack of a window manager. I am not familiar with your container system at all, but I am guessing from the startup command you showed that it is starting up only a terminal (xfce-terminal) and not the actual xfce window manager. So you get a terminal window from which you can launch new commands that may open additional windows, but there is no way of managing those new windows because the other relevant xfce components have not been loaded. Or maybe they are loaded but are not running. Anyway I think you need to pursue this at the container or xfce configuration level.
As to kitty or sixel as a fallback, I may not have been clear. The point of using either of those would be that they do not need to pop up a new window. They draw the graphics inside the same terminal window that you are already typing commands to. That would bypass the question of whether new windows are handled by a window manager. The xfce-terminal unfortunately does not support either kitty or sixel so far as I can tell from looking at the project web site. Do you have the option of starting your session with a different terminal (e.g. konsole, wezterm) that would support this kind of graphics, instead of xfce-terminal?
Dear @sfeam. You were completely correct that the issue with the window was due to the misproper window manager. I have solved the issue by making sure that the gnuplot module gets loaded inside the noVNC container (and not before launching it). Apparently, this makes a huge difference.
Thanks again for your patience. This ticket can be closed if you wish.
Regards
Ehsan