Automatic Download Button

I’ve been testing out some minimal JavaScript (and a Python script to format the GitHub release API) for the downloads.

This should present something similar to the Blender download page – auto-detecting your OS and architecture and presenting a “download” button as well as a fallback table with file sizes. It’s currently a self-contained html file with some JSON and JavaScript.

test.html.gz (1.7 KB)

Obviously it needs styling, but it might be nice to integrate into the main page and install page in some form.

Please give the test.html.gz a try and let me know if it works for your browser. My JavaScript is very minimal.

2 Likes

I tested it for my windows laptop and it is working for me!

1 Like

Tested on Windows 11 Pro w/ Firefox, works as expected.

1 Like

Great, I’ll see if I can integrate into the install page soon.

Affirmative, i.e. it worked well with Firefox (128.14.0esr (64-bit)) in an instance of Linux Debian 14/forky (testing) to fetch the corresponding x86-64 AppImage.

Okay, it should be active now at:

Feedback is always welcome.

1 Like

Just a quick suggestion, with the darkmode version of the website there isn’t much to visually highlight that part:

I’d recommend drawing a white box around the section that tells you the info about the version it is suggesting (Windows (x64) • 1.102.1 • 106.6 MB • 10/27/2025 in this case), just like with the part for Current Release and such, that way it stands out a bit more.

Sure, I’ll take a look at that. I need to switch up the nightly build links to the continual release anyway.

1 Like

@ghutchis I just observe Home in the top frame of the current setup of the discussion board (e.g., here) links to the elder documentation of “Avogadro1” (i.e., https://avogadro.cc/), hence subsequently to the no longer updated repository on sourceforge.

  • is this (still) intentional, given https://two.avogadro.cc ?

  • the GitHub hosted release page provides 64bit executables back till and including version 1.90.0 (published December 3rd, 2016), the sourceforge site’s old files back to the 0.1.0-win32.exe published 2007-05-15. Is it planed to consolidate the GitHub repository to equally provide these assets, then to close the sourceforge site – for instance after the release of Avogadro2 tag 2.000.0? I speculate this might / would reduce the likelihood of questions to the forum about “how to perform action x on model y” for the branch no longer actively maintained.

    If so (similar to the transient of Python2 → Python3), a note in advance to the visitors of the sourceforge page “by summer 2026 this site will close; for further information, visit two.avogadro.cc instead” (similar to the oude https://avogadro.cc) might be sensible.

1 Like

I cannot easily provide historical release assets for avogadro from avogadrolibs because they’re entirely different codebases.

In principle, I could create a bunch of old releases at cryos/avogadro (e.g., Tags · cryos/avogadro · GitHub) but that doesn’t make much sense.

As @brockdyer03 has mentioned, I think a lot of that goes away once the avogadro.cc website is replaced by two.avogadro.cc.

What’s happening now is people are searching for Avogadro, finding avogadro.cc or SourceForge and then downloading what they find.

I’m not entirely sold on closing out SourceForge. My plan was more to stick the 2.0.0 release up there, marking it as the latest release. I’m less certain on whether I can put a notice like you describe – SF.net has not been particularly flexible in that way, which is why many projects turned to GitHub and GitLab which display README files.

(Historically speaking, both avogadro.cc and avogadro.openmolecules.net are archived on archive.org.)

1 Like