Upgrade electron to '29.0.0-beta.8'

[SpecialAro]

Pre-flight Checklist

Please ensure you've completed all of the following.

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.

Description of Change

Upgrade to Electron v29

Motivation and Context

This is a WIP PR to prepare ourselves to upgrade to Electron v29. Currently v29 is on beta (v29.0.0-beta.5) - a full release should be out at February 20.

This PR fixes #1419

Tested in:

• Windows
• Linux
• MacOS

Checklist

• My pull request is properly named
• The changes respect the code style of the project (pnpm prepare-code)
• pnpm test passes
• I tested/previewed my changes locally

Release Notes

Upgrade electron to '29.0.0-beta.5'

[SpecialAro]

@mcmxcdev and @vraravam should we merge this Electron beta version to the nightly builds to prepare for the full release in February 20 ?

This way we could push a stable release as fast as possible so that users that were affected by #1419 could get a stable version faster.

[mcmxcdev]

@mcmxcdev and @vraravam should we merge this Electron beta version to the nightly builds to prepare for the full release in February 20 ?

This way we could push a stable release as fast as possible so that users that were affected by #1419 could get a stable version faster.

I am definitely in favor of this. Not too scared about it being a beta release (although Electron has a history of breaking things).

[vraravam]

previously, when i was doing the same - it was not appreciated.

My intention even then (and now) was to raise it as draft PRs and request the active contributors to build locally from source and test it out. I would suggest/vote for the same even now. ie do not merge into master, broadcast to all active contributors to checkout this branch and build from source code with the provided scripts, and run the app to verify functionality

[mcmxcdev]

You are always appreciated Vijay!

I would prefer to wait until a new major release matures and puts out patches first, but this zoom issue is a big problem for a lot of users, and we have let them wait a long time already.

I am on a business trip currently but I might be able to run it locally today and provide feedback!

[mcmxcdev]

Just tested it on Ubuntu 23.10 and it works great!

Zoom out doesn't work, only zoom in and reset zoom to default level, BUT that was already an issue like a year ago and is tracked on Electron somewhere iirc.

[SpecialAro]

Just tested it on Ubuntu 23.10 and it works great!

Zoom out doesn't work, only zoom in and reset zoom to default level, BUT that was already an issue like a year ago and is tracked on Electron somewhere iirc.

Nice! I'll mark it as checked and I'm testing now in macOS.

My intention even then (and now) was to raise it as draft PRs and request the active contributors to build locally from source and test it out. I would suggest/vote for the same even now. ie do not merge into master, broadcast to all active contributors to checkout this branch and build from source code with the provided scripts, and run the app to verify functionality

I agree with this as well. I'm testing myself on Windows and macOS but it would be good if other people test it as well.

Also, for the future, do you think it could be worth it to have some way to store the "builds" triggered by PRs? This way, users/maintainers could test versions way faster (downloading and running the packed app). I can try to investigate this further if you think it might be worth it!

[SpecialAro]

Just tested on macOS and everything seems to be fine. I'll ping other contributors to test this PR on their systems as well just to be sure.

[vraravam]

do you think it could be worth it to have some way to store the "builds" triggered by PRs? This way, users/maintainers could test versions way faster (downloading and running the packed app). I can try to investigate this further if you think it might be worth it!

Unfortunately, (based on past investigations), this is not possible using the "GH Releases" feature. We would have to merge to the develop branch, which will then trigger the nightly build, and only then will the Draft artefacts be created. (Draft is before any kind of publishing - whether its for nightly, beta or public/stable builds). AND, these "Draft" artefacts will not be available for any contributors that are not specifically approved in the Github org space. (I dont know whether "outside collaborator" will have this access either).

Which is why the "build from source" seems the simplest option as of now. If they are a code contributor, they must surely have the ability to build from source and run it locally. If so, then as core contributors, its our responsibility to ensure that the ./scripts/build-<OS>.sh scripts are maintained to work as expected.

[vraravam]

Tested the following functionalities on macos Sonoma 14.4 beta (on m2 mac):

1. Opening with a pre-existing profile
2. Older recipes were auto-updated as expected
3. Switching between services using keyboard shortcuts
4. Switching between workspaces using keyboard shortcuts
5. Haven't tried updating the main app (don't have cert-signed for local build)
6. Haven't tried audio/video calling in any service (jitsi, meet, discord are the services that i have configured which have such a feature)

[Alphrag]

To add to @vraravam's tests, I tried this PR on Windows 10 x64, MacOS Big Sur x64 as well as Fedora 34 x64, and can confirm that all of the following works as expected:

• zooming in and out, and resetting zoom with either shortcuts or menu items (cf video below);
• video calls (I tried with element);
• auto-updating for both Windows and MacOS;
• adding and deleting recipes.

So it seems quite good on my end for when the stable release of electron v29 will land.

Enregistrement.de.l.ecran.2024-02-08.a.23.20.09.mov

[SpecialAro]

Great 😁 thank you all for taking the time to test it! let's move to merge then?