Charting fails without `~/.eclipse`

LouisPM commented 1 month ago

Affects: OpenChrom snap package (vers. 1.5.0); incremental snap vers. 106 and 108

System Information:

OS: Ubuntu 20.04.1 LTS
kernel: 5.15.0-119-generic
display manager: X.org / gdm3

Steps to reproduce the issue:

Perform a fresh install of the snap app: snap remove --purge openchrom && rm -r ~/.eclipse && snap install openchrom # purge OpenChrom snap (if installed), remove local configuration files and re-install the snap
Launch the app, either from the desktop launcher, or from the terminal: /snap/bin/openchrom # is the binary executable referenced by the desktop launcher's Exec line
In the overview window, click on "Demo" to load the "DemoChromatogram8335379..." data.
Expectation: Chromatogram and m/z scan chart visible and populated with data. Observed bug: Windows are empty.

Bug description: On a fresh install of the OpenChrom snap package on Ubuntu, the application fails to load and display imported data. This issue can also be observed with the "Demo" data. Instead of chromatograms and m/z spectra, the corresponding windows show blank white fields.

Looking for an underlying cause I located the default executable: which openchrom # returned the path: /snap/bin/openchrom Running the executable from the terminal to launch OpenChrom (logs attached) throws a bunch of warnings and an error, most prominently:

(openchrom:11131): Gtk-WARNING **: 10:15:20.806: GTK+ module /snap/openchrom/106/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so cannot be loaded. GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported. Gtk-Message: 10:15:20.806: Failed to load module "canberra-gtk-module" WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign

Apparently, the app is not using the system library of the libcanberra-gtk-module: apt list --installed | grep libcanberra-gtk-module # check whether system library is installed; returned "libcanberra-gtk-module/focal,now 0.30-7ubuntu1 amd64 [installed]" The snap app is instead looking for its own version of the module at a non-existing path: ls -al /snap/openchrom/106/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so # returns "ls: cannot access '/snap/openchrom/106/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so': No such file or directory"

Thus, I looked at the last entry of the apps metadata log: cat ~/snap/openchrom/106/OpenChrom/1.5.x/.metadata/.log Multiple errors and exceptions had been caught. Among them the following (with variations):

!MESSAGE An error occurred while automatically activating bundle org.eclipse.swtchart.extensions (989).

java.io.FileNotFoundException: /css/default.css

While looking for a probable cause in the snap's directories, I found an alternative executable binary: /snap/openchrom/current/openchrom To my surprise the application launched without a hitch and correctly displayed the demo chromatogram (logs attached). Even more surprising was that any subsequent invocation of the default executable /snap/bin/openchrom now launched OpenChrom without the bug (logs attached), and this behavior persisted after rebooting the machine. And above-mentioned warnings and errors had magically disappeared from the terminal launch messages and metadata logs.

Perhaps, a persistent change (e.g. missing file or link) had been created by the non-default executable..? If so, this putative change would be unrelated to the above-mentioned Gtk-warning, as the path "/snap/openchrom/106/gnome-platform/usr/lib/gtk-2.0/" remains missing, suggesting that this warning was unrelated to the described bug after all. Correction: The Gtk warning is not thrown with /snap/openchrom/current/openchrom, but remains with subsequent executions of /snap/bin/openchrom; the path does not exist.

Proposed workaround: While the underlying cause remains elusive to me, running the following command once seems to fix the issue: /snap/openchrom/current/openchrom # alternative binary executable

Until the underlying issue has been identified and fixed, I suggest to circumvent the bug by changing the Exec line of the _openchromopenchrom.desktop launcher:

From (buggy):

Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/openchrom_openchrom.desktop /snap/bin/openchrom %f

To (working):

Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/openchrom_openchrom.desktop /snap/openchrom/current/openchrom %f

Attached files:

contents of the default desktop launcher (incremental snap vers. 106): openchrom_openchrom.desktop.txt
screenshot of buggy behavior when launched with .desktop launcher or /snap/bin/openchrom:
output when running /snap/bin/openchrom from the terminal: openchrom_buggy_terminal-output.log
output of cat ~/snap/openchrom/106/OpenChrom/1.5.x/.metadata/.log when launched by /snap/bin/openchrom: openchrom_buggy_metadata.log
screenshot of expected behavior, after having executed /snap/openchrom/current/openchrom once (the same for subsequent executions of /snap/bin/openchrom):
output when running /snap/openchrom/current/openchrom (for the first time) from the terminal: openchrom_expected_terminal-output_first.log
output of cat ~/snap/openchrom/106/OpenChrom/1.5.x/.metadata/.log when launched by /snap/openchrom/current/openchrom (for the first time): openchrom_expected_metadata_first.log
output when running /snap/bin/openchrom from the terminal, after having been launched by /snap/openchrom/current/openchrom sometime before: openchrom_expected_terminal-output_second.log
output of cat ~/snap/openchrom/106/OpenChrom/1.5.x/.metadata/.log when launched by /snap/bin/openchrom after having been launched by /snap/openchrom/current/openchrom sometime before: openchrom_expected_metadata_second.log