Teething troubles with 1.96 AppImage

Long time browser of the forums but my first time posting as I would appreciate a little help. Thanks to @ghutchis and all contributors for their excellent work on Avogadro. I really care about the project and as such, might even try to contribute myself in the future. Now, for my issue:

Previously I have had problems trying to run Avogadro 2 on my linux machine, even though it works perfectly on my Windows computers. As such, I was excited to have the AppImage option with the new release, as I assumed the problems were to do with the Flatpak implementation or with my system. Unfortunately, Avogadro still doesn’t work. After making the AppImage executable and executing it, all that opens is a an empty black window. Nothing else is shown. Closing the window brings up the usual save or discard your work? message box when quitting Avogadro.

Environment Information

Avogadro version: 1.96.0 AppImage from GitHub
Operating system and version:
Operating System: openSUSE Tumbleweed 20220602
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.2
Kernel Version: 5.18.1-1-default (64-bit)
Graphics Platform: Wayland

The following text gets printed in the terminal:

qt.qpa.plugin: Could not find the Qt platform plugin “wayland” in “”
Locale: “en_GB”
AvogadroApp Translation “en_GB” loaded “/tmp/.mount_AvogadsSpufu/usr/bin/…/share/avogadro2/i18n/”
AvogadroLibs Translation “en_GB” loaded “/tmp/.mount_AvogadsSpufu/usr/bin/…/share/avogadro2/i18n/”
Translated quit: “&Quit”
Extension plugins dynamically found… 43
Checking for “commands” scripts in “/home/[username]/.local/share/OpenChemistry/Avogadro/commands”
Checking for “commands” scripts in “/home/matt/.local/share/flatpak/exports/share/OpenChemistry/Avogadro/commands”
Checking for “commands” scripts in “/var/lib/flatpak/exports/share/OpenChemistry/Avogadro/commands”
Checking for “commands” scripts in “/usr/share/OpenChemistry/Avogadro/commands”
Checking for “commands” scripts in “/tmp/.mount_AvogadsSpufu/usr/bin/…/lib/avogadro2/scripts/commands”
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
OBProcess::executeObabel: Running “/tmp/.mount_AvogadsSpufu/usr/bin/obabel” “-L formats read”
OBProcess::executeObabel: Running “/tmp/.mount_AvogadsSpufu/usr/bin/obabel” “-L formats write”
OBProcess::executeObabel: Running “/tmp/.mount_AvogadsSpufu/usr/bin/obabel” “-L forcefields”
OBProcess::executeObabel: Running “/tmp/.mount_AvogadsSpufu/usr/bin/obabel” “-L charges”
OBProcess::executeObabel: Running “/tmp/.mount_AvogadsSpufu/usr/bin/obabel” “-V”
“/tmp/.mount_AvogadsSpufu/usr/bin/obabel” found: “/tmp/.mount_AvogadsSpufu/usr/bin/obabel: Open Babel 3.1.0 – Jun 2 2022 – 22:45
:08”
Checking for “inputGenerators” scripts in “/home/matt/.local/share/OpenChemistry/Avogadro/inputGenerators”
Checking for “inputGenerators” scripts in “/home/matt/.local/share/flatpak/exports/share/OpenChemistry/Avogadro/inputGenerators”
Checking for “inputGenerators” scripts in “/var/lib/flatpak/exports/share/OpenChemistry/Avogadro/inputGenerators”
Checking for “inputGenerators” scripts in “/usr/share/OpenChemistry/Avogadro/inputGenerators”
Checking for “inputGenerators” scripts in “/tmp/.mount_AvogadsSpufu/usr/bin/…/lib/avogadro2/scripts/inputGenerators”
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Checking for “formatScripts” scripts in “/home/matt/.local/share/OpenChemistry/Avogadro/formatScripts”
Checking for “formatScripts” scripts in “/home/matt/.local/share/flatpak/exports/share/OpenChemistry/Avogadro/formatScripts”
Checking for “formatScripts” scripts in “/var/lib/flatpak/exports/share/OpenChemistry/Avogadro/formatScripts”
Checking for “formatScripts” scripts in “/usr/share/OpenChemistry/Avogadro/formatScripts”
Checking for “formatScripts” scripts in “/tmp/.mount_AvogadsSpufu/usr/bin/…/lib/avogadro2/scripts/formatScripts”
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Python interpreter “/opt/hostedtoolcache/Python/3.10.4/x64/bin/python3” does not exist trying “python” in your path. Please set a pat
h to the python interpreter.
Error starting RPC server: “QLocalServer::listen: Address in use”
Starting new server.
Open Babel formats ready: 143

I did already try running under X11 instead of Wayland but only the first line is removed from the error message, and when Avogadro opens the window is transparent as opposed to black, but otherwise displays nothing.

Clearly the path to the python interpreter is a significant issue but I don’t understand why Avogadro would look in a location in /opt that doesn’t exist anyway? Not entirely sure how to fix the issue, and I feel like it is likely to be an issue for many users.

Many thanks in advance.

As far as the Python question… we build our binaries on the GitHub infrastructure. Since these build servers contain multiple versions of Python, this is the path on the build server. (And thus the fallback comment.) It will go away if you set a path to python in Avogadro:

Extensions => Set Python Path…

As to Wayland … this is a known bug: Will Avogadro support Wayland?

We should be able to switch away to a different OpenGL library in the next release.

Thanks for the suggestions and response :slight_smile:

So it turns out the program does start correctly (on X11 at least), and it’s just that the window remains empty (no menus or anything) until I click within the window. Which is odd behaviour though to say the least, and would confuse any new user, but I think I remember reading about that bug? It seems to be linked to the more general problem that almost every single piece of visual feedback given within Avogadro (a checked box, a selected atom, choosing a different tool from the top menu, appearance of automatic hydrogen atoms after addition of a new atom, and so on) always appears only after something else is clicked. Only drop down menus appear immediately. This has the result that when selecting atoms for example, what is displayed is always one step behind what’s just been selected, if that makes sense. All very odd, but at least it works now

That’s very odd. Could you do a screen recording?

It is odd! I’ve made a screen recording that shows the general behaviour I’m experiencing. Where can I send it to? Would prefer to send it via email or similar rather than post it publicly

(As an aside - interestingly, if I install Avogadro (1.95.1) via the zypper package manager in opensuse, the “delayed response” is also present. Furthermore, drawing molecules doesn’t even work properly, so that at least has been fixed with the 1.96 AppImage. On the other hand, when Avogadro 1.95 is started the full UI appears immediately, not a blank or transparent window like in 1.96.)

You can find my e-mail, or send via a DM here on the forum.

It seems some of these are issues with the AppImage binary itself, which is definitely new in this release.

I would guess SuSE and other distros should have packages fairly soon and hopefully that should fix some issues. I’m looking into generating our own RPMs.

The Debian build for 1.96 is already available (for debian unstable and testing). There is indeed some problem with the interface, though there were already problems previously before 1.96. It seems to be related to patches for GL support on the one hand and the layer selection patches on the other hand, both affecting rendering.

The symptom for me is that the molecule goes invisible and sometimes the window goes transparent, related to the window state. Transparent window when fullscreen, but can see the molecule when the window is not full-screen and gets moves.

Then also the rendering glitches, toggling labels, ball&stick rendering. It’s behaving as if updating the canvas gets out-of-sync with changes (by way of labels or atom display type) to the image.

The problem is a bit hard to make sense of which is why I haven’t filed a bug report yet (apart from Issue#826).

1 Like

We ask for a transparent OpenGL context so that we can copy the molecule rendering without the background.

Perhaps one initial workaround would be to not ask for a transparent context on Linux. It’s nice to copy without background, but not worth these UI bugs. I can patch that tonight.

Hmm. Seems like something isn’t always calling for a refresh?

If anyone can help find a testable use case, e.g., “do this and this, but the render doesn’t update,” please let me know and I can look into it more closely.