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: https://github.com/JabRef/jabref/issues/11082

The underlying issue is https://github.com/JabRef/JabRefOnline/issues/2176. There was a fix attempt made (https://github.com/JabRef/JabRefOnline/issues/2176#issuecomment-1687012154), but it was rejected in favor of a "far better" solution (https://github.com/JabRef/JabRefOnline/issues/2176#issuecomment-1688953053). 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 https://github.com/JabRef/JabRefOnline/blob/947af7d7e9eaaec9f74cc1492bf86f01186fce2c/composables/downloads.ts#L1, 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[bot]]

Deployed 947af7d7e9eaaec9f74cc1492bf86f01186fce2c 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.

[tobiasdiez]

Closing this due to inactivity :zzz:

[koppor]

@tobiasdiez Please help us to get this fixed. Please provide a workaround for https://github.com/JabRef/JabRefOnline/issues/2176

We can implement a good solution if someone of us has time. We need a workaround to keep users. I think, one reason they switch to Zotero is the WTF download

https://star-history.com/#JabRef/jabref&zotero/zotero&Date

[tobiasdiez]

@tobiasdiez Please help us to get this fixed. Please provide a workaround for #2176

I've already described a possible workaround in https://github.com/JabRef/JabRefOnline/pull/2359#issuecomment-2020091118. I don't have a mac so I'll not work on this myself.

I think, one reason they switch to Zotero is the WTF download

Well, the difference in users just comes from the fact that Zotero is open to every scientific field, while JabRef's limited scope as a bibtex editor only appeals to very few people in STEM - and even then, some of them just don't care about "correct" bibtex and are perfectly fine with whatever output they get from zotero + better bibtex. If you want to have more users, then just reduce the emphasize on bibtex and make jabref a more general reference manager that just happens to use bibtex as the backend.

[koppor]

I've already described a possible workaround in #2359 (comment)

There is no Linux in that workaround. Can you please add it and then roll out the fix?