Support gnu/linux distribiutions
LinArcX opened this issue · comments
- Configure AppImage build
- Add application icon
- Fix Controls menu items
- Enable code signing (?)
- Enable AppImage build on the pipeline
- Add Linux related docs and links to the website
- Release a new version
Yes, it would be nice! I guess SoundCleod could be made to work on Linux with minimal modification.
Packaging and distributing and might be trickier. What's the cross-distro way of shipping standalone Linux apps nowadays?
Anyway, contributions in this direction are welcome!
@salomvary packaging and distributing is quite simple since AppImage is a thing.
Since you use electron it should be as simple as including:
"linux": {
"target": [
"AppImage"
]
}
into your package.json "build" object.
I just stumbled across this project, but if it's soundcloud in an electron wrapper with the menu bar to control everything, then building with that seemed to work just fine.
The only things that didn't seem to work was the menu items in Controls.
I'd just assume they don't work from clicking the menu buttons because the application is focused, from seeing the code:
menu.events.on('nextTrack', () => {
if (isNotFocused()) soundcloud.nextTrack()
})
(Should the focus check even be there? The menu items work if I remove the if check. I see some comments about double registering.. Maybe you could have two event emitters, one from the context menu with a "-menu" suffix that doesn't use the if check, and another without that does use the if check.)
The application icon also won't work with the AppImage unless you put it inside of the BrowserWindow construction, but that's as simple as setting the icon var in the object
@salomvary if you say me how to build/run the program from the source, i can package it for archlinux AUR Repository too. for ubuntu and fedora other guys can help and as @TSedlar said, appimage is a cross distro approach.
@TSedlar thanks for the investigation! Sounds like we are pretty close:) The isNotFocused() thing probably needs a closer look from me.
@LinArcX We have some (partially outdated) development docs in DEVELOPMENT.md. You can build the LinuxAppImage by running npm install && npm run dist -- --linux (assuming you have npm installed).
Is code signing a thing with AppImages? I guess we should set that up too.
@LinArcX Btw we use a tool named electron builder for producing distributable images for various platforms. According to the docs it supports AppImage, snap, debian package (deb), rpm, freebsd, pacman, p5p, apk for Linux.
Is the AppImage build available for download somewhere? If not, what is holding it back? Thank you.
@probonopd no AppImage is published as the Linux integration is not complete yet (see the TODO list at the top os this issue). If you are curious you can generate an AppImage yourself by running npm run dist -- --linux (assuming you have the project set up locally).
Contributions to completing that TODO list are always welcome.
I've spent the last 2 days working on getting this to run in Linux smoothly. Here's where I am:
- AppImage and Snap builds, the latter runs using AppArmor sandboxing
- Control menu and accelerator keys work as expected
- Media keys work as expected with occasional funky behavior on behalf of gnome (as far as i can tell)
- Application icon works
- OS Media player integration works using a custom MPRIS2 client as snap sandboxing prevents chromium from exposing that interface. As a bonus, we get album artwork:
I had to modify electron-builder for that. (Never mind the failing CI on that pull request - current master also fails), so i won't be submitting a pull request yet. You can check out my changes here.
@salomvary Please have a look. The behavior of the control menu items is probably different from OS to OS - if you could check if they work as expected on MacOS and Windows, that'd be great. Let me know if there is anything you want me to change (i.e. break it up into smaller commits) or if that is acceptable to you.
If you do not want to wait for electron-builder to get updated, we can temporarily depend on a custom build of the affected module. Let me know.
Next up would be documentation and setting up code signing and publishing to the snapcraft store - do you want me to set that up and hand over the keys to you?
Hey @ponyfleisch thanks a lot for contributing!
What do you think about making the AppImage distribution work first? As far as I understand that's something that should work for everyone and Snap is the "next level" of packaging support.
This way we would require fewer changes, for example the existing MediaSession integration would work out of the box (if I clearly understand your code comments). We also don't need to use an electron-builder fork or wait for the changes to be released.
Regarding code signing and other credentials: signing AppImages seems to be optional, we can do that later but adding instructions to MAINTENANCE.md would be save me a lot of time and head-scratching:)
Same for the Snap store credentials. I would prefer to be in control of the credentials (including creating them), maintainer instructions would definitely speed things up.
Keep in mind I have close to zero experience in shipping packages for Linux, any advice will be useful in this direction.
Anyway, I suggest sending a pull request with the smallest possible changeset that gets us a working Linux package.
Btw the control menu has problems on all platforms, not specific to Linux: #207
The way I fixed the control menu is by simply ignoring the menu action when using the keyboard. Which means the Shortcut indicators in the menu are technically just for show.
AppImage vs. Snap: Sure, I'll check out how we can progress on the AppImage. But I'd stick to the custom mpris integration as it supports artwork, unless you object to introducing dependencies. Note that AppImage does not seem to provide any sort of sandboxing as far as I can tell.
Noted on the credentials and signing - but I do not have any experience with Snap so I can't really contribute much. Will see what preparatory work can be done.
The way I fixed the control menu is by simply ignoring the menu action when using the keyboard. Which means the Shortcut indicators in the menu are technically just for show.
Neat, I was not aware of event.triggeredByAccelerator!
Unfortunately, this change breaks the menu on macOS when the app is in foreground but has no window open (yes, that's possible on macOS:). In this case you should still be able to use the accelerator keys but they will be ignored (because events are also not sent to SoundCloud's own handlers as there is no window visible).
I guess we should have something like if (!event.triggeredByAccelerator || isNotFocused())
I'm familiar with MacOS, been using it for the last decade, switching back to Linux now for a bit. But if there is no window open, I assume there is also no browser context and no music playing?
@salomvary sorry - just to be absolutely clear, what's the expected behavior on macOS when there is no visible window and one of the control menu items is activated via keyboard?
But if there is no window open, I assume there is also no browser context and no music playing?
When you close the main window, it does not actually get destroyed, only hidden:
https://github.com/salomvary/soundcleod/blob/master/app/main.js#L111-L129
what's the expected behavior on macOS when there is no visible window and one of the control menu items is activated via keyboard?
If the is no visible window but SoundCleod is in the foreground (or "active", whatever the right term is) the behavior should be the same as if the main window was active in the foreground. That means the controls menu and the keyboard shortcuts should work (eg. "space" starts/stops playback).