For what it’s worth, I’m likely to continue creating NSIS installers simply because it seems the MSIX packages have to be code-signed and that seems difficult on a nightly build.
Just note that when I was improving the Linux metadata I settled on this option purely because it aligns with the first sentence of the repo READMEs. Wanted to match the rest of the project rather than being opinionated.
I don’t actually love this description, partly because I think “Advanced” is a bit meaningless, and partly because I think “molecular editor” without qualification is more likely to suggest a 2D editor in people’s minds. Whereas I think “visualizer” is not generally an action people would associate with 2D structures so makes the 3D aspect a bit clearer.
So I would tend to prefer your other suggestion, which I think is good. “3D molecular editor” would also work IMO, but I prefer “Molecular editor and visualizer” personally.
I can do that for releases with SignPath (fingers crossed) or upload to the MS Store in which case Microsoft will sign it.
In principle, I could issue a self-signed certificate for the MSIX, but then you’d need to trust the certificate before installing, which seems .. not great.
I have uploaded the nightly build to the MS Store and we’ll see how long that takes.
(Incidentally, this is encouraging me to submit releases to the Mac App Store as well. People are selling vibrational visualization for US$ 17.99)
Just double checking, the NSIS installed a version of Avogadro that was built with Qt5, not Qt6. Hopefully that’s the intended behavior for that!
I still need to work on getting the Qt6 stuff sorted for Windows, currently the holdup is that the builds are trying to use Qt 6.9.3 but I have Qt 6.8.1 installed locally and Qt is being a pain about just adding in another version of Qt to my install path. Once I get that done I can actually use windeployqt on the builds from the github page to get an executable and try to zip things up the right way for an installer.
To be honest, I usually don’t set Avogadro 2 as the default for anything since I usually edit .xyz files by hand, and I don’t use .cjson very often since most programs I use in my workflow can’t parse .cjson natively. That is all to say that I actually don’t know if any of those files are properly defaulted by the installer.
Would have thought people who have crystallographic software installed (Mercury etc.) might be annoyed if Avogadro seized the default file association for CIF files. Though perhaps it doesn’t set itself as the default, just registers itself as being capable of handling the format.
You can check that in your Windows settings under Apps > Default Apps
I checked the file extension associations, and .cif is set to Avogadro 2, as are .mol and .mol2, but .xyz is not set to Avogadro 2. It looks like if there is already an application set for the file association then Avogadro 2 will not overwrite it, so I’d say that it’s fine to include those formats in the list.
I don’t think Windows actually has a list of file formats that Avogadro 2 is “capable” of handling, since if I pick something like a .h file it will list Avogadro 2 as an option for opening it, even if it will actually fail to open it.
BTW, it looks like the Microsoft store wants at least 4 screenshots on Windows desktop.
If you or anyone else has some exciting screenshots (e.g., visualizing molecules, orbitals / surfaces, spectra, etc.) I’d welcome them - both for the MS Store as well as the manual.
I went to go get some exciting screenshots that highlight what Avogadro 2 can do, and realized that the version I have from the installers you just sent crashes when opening an ORCA output. Then I went to download the nightly build from the website, only to realize that there is no executable in the nightly on two.avogadro.cc.
I went back through the installers that I have saved locally (I knew forgetting to delete all of my old installers would be useful some day), and the earliest download that I have that has the bug is from 10/9/2025 and used avogadrolib version 1.101.0-155-gbc2c7194. The latest version that I have that doesn’t have the bug is from 9/30/2025 and used avogadrolib version 1.101.0-71-gcc972e3d.
Also, Release 1.101 doesn’t crash for the molecular orbitals, but I also noticed there’s no “Plot Spectra” button (even though the later nightlies do have it), which I was going to use for another screenshot.
Even weirder is that after I switched to my desktop it stopped crashing with ORCA outputs. Even more weird is that when I opened up my laptop and tried opening an ORCA output again it seemed to stop crashing as well.
The best bugs are the ones that magically fix themselves?
There were some example NSIS scripts that included “upgrade” = uninstall previous version + install the new version. Unfortunately, I couldn’t get that to work at first go.
So it’s possible you had the Qt5 buggy version and the newer Qt6 version? Dunno. I’ll see if I can get the “upgrade” section working for the NSIS installer before the Oct 23rd release.
Having had to prepare some screenshots for the Flatpak, I’d strongly recommend using a smaller window to make the screenshots:
At 1920×1080 UI elements end up quite small relative to the window, making it hard for potential users browsing an app store to assess the UI from the screenshots
Screenshots are rarely viewed full screen, so 1080p images aren’t displayed at native resolution but instead scaled anyway, so small text becomes blurry
Many people use laptops with scaling, meaning that their effective resolution is smaller than 1080p (for example, at the default 150% scaling my old Surface Pro had an effective resolution of 1824×1216; the newer 13 inch ones are effectively 1920×1280 but the 12 inch is eff. 1464×976)
The Flathub quality guidelines recommend a very small (far too small, IMO) size of max 1000×700 including shadows. You can see from the primary screenshot on Flathub (image hosted here) that that size cramps the Avogadro UI quite a bit (and that screenshot isn’t even small enough, it’s 1097×971! But any smaller and the toolbar icons disappear). But you can also see how much more visible it makes the UI for people assessing the program, e.g. also in the Discover app store on KDE:
I’d suggest that going forward we standardize on 1440×900 for all screenshots, as it’s a size that fits with all the concerns above and complies with all the guidelines (other than the stupid Flathub ones). That way we can have a consistent appearance in the docs and on the homepage, and we can easily reuse the screenshots in different places.
Oh and in screenshots like these ones I think it’s best if the dialogs aren’t tiled like you’ve made them but instead a bit more separated from the window edges, so it’s clear that they are normal floating dialogs.
Otherwise, I think it’s an excellent, well-chosen selection of images that nicely displays Avogadro’s common uses, capabilities, and beautiful rendering. Maybe the protein example could be something that looks a bit more proteiny, but other than that no criticisms.
Indeed, it’d be great if you could also take screenshots of the same things but with a white background and no UI so that they can be potential options for places like the homepage.
Speaking of which, it’d be good to also put a screenshot or two in dark mode on the MS store to demonstrate its existence, given how nice it looks and how much it means to many people
Maybe the protein example could be something that looks a bit more proteiny, but other than that no criticisms.
