Installed via the
apt package manager (equally recommended here), flatpak for Debian 11/bullseye was version 1.10.2-3. With the stability stability of OS installed in mind, I did not intend to mix packages from testing* with more recent ones from sid/unstable (according to the package tracker offering 1.11.3-1), or experimental. As by today (2021-08-26), the more recent version did not transitioned into bullseye, nor testing (e.g. currently labelled as “Too young, only 0 of 5 days old”).
I’m not convinced starting Avogadro from an entry of the program launcher/GUI or from the CLI is going to yield different results; eventually, both calls start a program which relies on a graphic library to display the buttons, visualize the molecule, etc. It is not like OpenBabel one may comfortably run (for one or a few data) via GUI (
obgui), and equally/more performant for larger batches of structures from the CLI (which then remains in the CLI) via
bash, or a script (e.g., Python).
*) Since August 14th, Debian 11/bullseye no longer is in branch “testing”, but “stable”. To continue with the more frequently updated branch testing (then Debian 12/bookworm), I still await the transition e.g., of base-files from 11.1 to 12, still labelled as “Too young, only 3 of 5 days old” and “Waiting for test results, another package or too young” (at least by today, 2021-08-26). However, in branch testing functional updates are more frequent than in branch stable (the later prefers updates if these patches relate to security).
This is based on your note
“I plan to update to 1.95.1 skipping 1.95.0, due to another blank window issue at the moment.”
(emphasis added by mine), and again, I don’t know the cause, nor development around/with flatpak at all. However, is there something like an intentionally isolated environment where you work and test Avogadro for/in flatpak (e.g., for a session in Windows, Linux, Mac) before it is published?
When working with Python, I use both modules/packages from the standard library present in any default installation of CPython, as well as other ones. The simultaneous use may be a problem if the later ones are installed system wide, namely: when the code written is shared as such with a colleague who uses an other default installation of Python: one may forget to mention the additional (implicit) dependencies. As a result, some functionality differs from the anticipated pattern.
Python’s virtual environments offer one solution to this problem because a) one starts with a default, pristine Python (independent from what otherwise is the installed/personalized Python in the OS). And b), any non-standard module the code to be written depends on explicitly has to be named/installed/managed. Thus, it is easier to prepare code for share with others.
Based on this experience in Python, I speculate such sandbox-like containers for the project “Avogadro in flatpak” could be useful to test the functionality e.g., to simulate a session in Linux as hosting OS. But by lack of experience with flatpak, I don’t know if this might be a useful approach for you.