Wayland support

[spazziale]

To use electron-based applications natively under Wayland, the following flags need to be added to your application exec command line (for Electron 20): --ozone-platform-hint=auto.
With the flatpak version I doesn't works

[waldo121]

Nuclear uses electron version 12 of electron. So this change is impossible to make right now. The electron dependency needs to be updated first. I wonder if there are arguments against bumping electron to something more recent.
https://docs.flatpak.org/en/latest/electron.html#sandbox-permissions related docs.

[nukeop]

One major problem with newer versions is that they change the way IPC works, and since Nuclear uses IPC heavily, it would be a lot of effort to migrate that. Those parts are also very weakly tested, so it's hard to make the migration with confidence.

[waldo121]

No matter how tedious it might be, I wanna get it done. I think it's worth the effort also because it's almost been 3 years that there are no more updates. Hopefully I can also figure out a way to write tests for those IPC.

[waldo121]

A couple of the issues Ive met so far trying to bump electron to the latest major version(33), for visibility:

• Extending Electron App interface with transformSource() does not work anymore -> no idea why, haven't looked deep into this yet.
• Electron-timber version 1.0.0 breaks. I believe this is because the dependency is now an ESM module and something else is required to make it work with the same js flavor than @nuclear/main, @nuclear/core and @nuclear/app e.g. a typescript config.

At last, I noticed the no-sandbox, which is not recommended for production docs. So, why is it used?

[nukeop]

electron-timber is old, limited, and umaintained. Last time I tried updating Electron I had to reimplement this myself from scratch (my bad for relying on anything made by that sindresorhus guy). He takes a hardline stance on ES modules, trying to force packages that import his modules to use them. You can tell because he deliberately breaks CJS compatibility even if there's no reason too. The only way he even updated that package was to break compatibility on purpose after several years of not maintaining it. He didn't change anything else. My tip is to never use anything released by or contributed to by that guy.

[waldo121]

This looks like a simple, better maintained alternative to the logging problem https://github.com/megahertz/electron-log. Have you seen/considered it before?

[nukeop]

This is fine, though it solves only a small part of the problem. I haven't tried it. Implementing something like that directly in Nuclear is also possible.

[waldo121]

I moved the logging discussion to a new issue #1734. The topic was drifting from original post.