Wayland support - Githubissues

nukeop / nuclear

Streaming music player that finds free music for you

https://nuclearplayer.com

GNU Affero General Public License v3.0

12.25k stars 1.07k forks source link

Wayland support #1464

Open spazziale opened 1 year ago

spazziale commented 1 year ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

I moved the logging discussion to a new issue https://github.com/nukeop/nuclear/issues/1734. The topic was drifting from original post.