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).
Addition:
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?
Background:
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.