feat: make downloads working better for Debian and macOS users

[koppor]

Users with a recent Mac (starting from the M1 machines) get the wrong macOS binary. Therefore, raising issues in JabRef repo again and again and binding our spare development resources. - Example: JabRef/jabref#11082

The underlying issue is #2176. There was a fix attempt made (#2176 (comment)), but it was rejected in favor of a "far better" solution (#2176 (comment)). However, no one implemented this.

I perceive that we upset users and force some users to stay at old versions. Our JabRef strategy (since about 10 years) is to "force" users to update to a new version - and make this transition smooth.

Thus, we should get the "quick fix" in - and work on a "perfect" fix later on.

[koppor]

Pipeline fails at the first steps:

OK, a PR might be considered "unsecure", but I don't understand why a branch from the same repository is considered unsecure.

[tobiasdiez]

Users with a recent Mac (starting from the M1 machines) get the wrong macOS binary. Therefore, raising issues in JabRef repo again and again and binding our spare development resources. - Example: JabRef/jabref#11082

I think it would be good to detect this on the start of JabRef and report an error. Even if the download link redirects to the general fosshub page you are bound to have users that download the wrong binary.

Thus, we should get the "quick fix" in - and work on a "perfect" fix later on.

Note that this "quick fix" is a regression for everyone not having a new mac system.

If you don't want to work on the redesigned download interface (which I can understand), a "good enough" solution for now would be the following:

• In

  JabRefOnline/composables/downloads.ts

  Line 1 in 947af7d

  export function constructDownloadUrl(): string {

  , add special handling of macos. Namely,
• navigator.userAgent.match(/OS X 10_([789]|1[01234])/) then its not arm (since silicon exists only with 10_5 or higher)
• navigator.userAgentData.getHighEntropyValues exists, then use it to obtain the architecture (this should work on modern chrome browsers
• fallback to generic download url

[tobiasdiez]

OK, a PR might be considered "unsecure", but I don't understand why a branch from the same repository is considered unsecure.

Good suggestion. Happy to receive a PR.

[github-actions]

Deployed 947af7d to https://gentle-forest-03418aa03-2359.westeurope.3.azurestaticapps.net

[koppor]

Note that this "quick fix" is a regression for everyone not having a new mac system.

Yes, but the download used to work before. Even with a click more.

Sometimes one needs to accept a step back to get things working.

[koppor]

If you don't want to work on the redesigned download interface (which I can understand), a "good enough" solution for now would be the following:

Thank you for understanding the challenge of addressing the redesigned download interface at this moment. Our immediate focus is on supporting our GSoC students and addressing bugs in JabRef. This prioritization allows us to ensure the stability and functionality of JabRef, benefiting our user community at large.

I acknowledge the importance of the download interface and the need for a solution that does not hinder user experience or contribute to users staying on outdated versions. Our goal has always been to facilitate a seamless transition to new versions, emphasizing user satisfaction and engagement.

I am aware of the concerns regarding macOS users and the potential impact on their experience. Addressing this issue remains a priority, and we aim to implement a temporary solution promptly. A more comprehensive fix will be explored as soon as our current commitments allow for additional bandwidth.

The feedback regarding FOSShub and the observed decrease in download numbers is being taken seriously. It underscores the necessity of a swift response to maintain trust and satisfaction within our community.

We are committed to implementing a "quick fix" to immediately address the most pressing concerns, with plans to develop and apply a more refined solution in the future. Your patience and understanding as we navigate these challenges are greatly appreciated.

[Siedlerchr]

Normally, x86 programs work on Mac arm as well, they just use Rosetta emulation. However, seems to be problematic with java/javafx and performance wise degraded.

And linux users will also need to choose the right one for their system.