Home   Manual

Avogadro2 is on Flathub

For Linux user only.

No need to compile from source anymore! Avogadro is available in Flatpak format, you can now install from Flathub.


Read setup guide to setup Flatpak before installing.

If your software manager support installing Flatpak, try it first.
Install it with
flatpak install flathub org.openchemistry.Avogadro2

Avogadro2 icon should appear in your desktop menu.

1 Like

To install plugins
Plugin downloader does not place the plugin in the correct directory as for now.
For example, to install InputGenerators. Place the content of the plugins here. Create new folder if necessary.


I have tried to do what you have suggested. I am using Mint 20.1 cinnamon.
When I try to open avogadro2, I get a blank window only.
Any idea about the error?

On the other hand, I tried to find the QT5, can anyone share the link from where I can download it?

1 Like

In an installation of Linux Debian 11/bullseye (for less than a week eventually considered stable) and the Xfce4 desktop environment, I followed the instructions and still share the observation by @prasanta13 – there is just a blank, actually just a transparent window:

Because I’m not a user of flathub, I perceive the download to get Avogadro comfortable too large. E.g., the download:


with a total of 1.5 GB of space used when eventually installed. So I hope the newer version 1.95 of Avogadro announced here enters soon the package tracker on debichem, e.g. for then (hopefully) functional extensions to prepare jobs for MOPAC, GAMESS, etc.

Till then, it may be better to let apt to manage a local installation of Avogadro (including resolution of any dependencies) than to implant almost a second operating system.

I don’t know the merits of Flatpak vs. Snap vs. AppImage. If someone would like to try to put together a Snap or an AppImage, we can give that a try too.

Exactly the same thing happened with me.

@prasanta13 @Thomas
I recently submit a new pr to update to version 1.95.0.

Let me know if your problem still happen.
I have an issue with Avogadro 2 1.95.0 as well.
The background is not transparent and UI still exist, but I cannot see any molecule. Not sure what happen.

@ghutchis Flatpak, Snap, AppImage are app container with bundle dependencies, they follow the same idea. I think thomas meant apt as a traditional package manager. Which package manager would share the dependencies with other package making it small.

Yes, that’s a reported bug - the “Ball and Stick” display type is somehow not turning on by default. If you click the box, everything should be good.

Tomviz is now on Flathub.

@kevinsmia1939 Assuming there would be a more general problem in the interaction between Avogadro and Flathub, I disembarked from Flathub entirely. Avogadro would have been the only program in profit by this interface.

At least by today (2021-08-25), Debian’s package tracker is aware of Avogadro 1.95. Thus, it is only a matter of time when one of the maintainers of debichem is going to make it available for Debian sid. And if there isn’t a significant problem for Debian sid, the package will transition into Debian testing about one to two weeks later, with the typical ramifications e.g., for Linux Mint and Ubuntu.

Till then, I’ll collect the structures of interest and process a batch of them (e.g., generation of input files for MOPAC) with «old Avogadro» (version 1.2) as running in an installation of Xubuntu 18.04 LTS. At present, this additional transfer of data and a reboot of the computer to enter an other OS is acceptable for my workflow.

What is your flatpak version on your debian?
flatpak --version
If you don’t mind, could you try update to latest version, 1.11.3?

And also your hardware specs.
Maybe there will be useful info when running flatpak avogadro through terminal.
flatpak run org.openchemistry.Avogadro2

I plan to update to 1.95.1 skipping 1.95.0, due to another blank window issue at the moment.

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.

I was referring to this issue.

Which is fixed in the next release.
What I mean about starting avogadro from cli is to see if there is any error log shown.

I test my flatpak apps on my machine (openSUSE Tumbleweed, lenovo legion Ryzen 5 4600H, GTX 1650Ti) before it is publish of course, but I do not have other hardware to test it on.

I am not avid Avogadro user, so I can’t test all the functionality.

Annyway, what is your hardware spec?

I just push 1.95.1 to Flathub, will probably be update in a few hours.
I could not build avogadrolibs on ARM arch. So I disable the build for it at the moment.


Avogadro2 1.95.1 is available now.


1 Like

There’s a pull request to build Flatpak with each GitHub change and release. I’m wondering if:

  • This would be useful (e.g., to have bug-fixes before the official Flatpak updates)
  • It makes sense to build for each change (i.e., I’d probably have a separate manifest from @kevinsmia1939)


I not familiar with github action and how to use it. But I think that the manifest that Flathub use can be use with this with minimal change.

I think that this would be useful to ship new features and bug fixes very quickly.

1 Like

Yes, I think we just need a script that removes the tag and commit hash from the avogadrolibs and avogadroapp YAML entries. I have a draft, so I’ll give it a try later today.

Here’s the pull request:

It’s having problems because glew.json (and presumably others) don’t exist in the local folder. Is it worth creating these, or is there another solution?