Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Menu Bar Issues #1647

Open
T0Pat opened this issue Jul 18, 2024 · 4 comments
Open

Menu Bar Issues #1647

T0Pat opened this issue Jul 18, 2024 · 4 comments
Assignees
Labels
feature request This is a request for the addition of some feature.

Comments

@T0Pat
Copy link

T0Pat commented Jul 18, 2024

Platform:
Mac: macOS Sonoma 14.5
Nuclear version:
0.6.31
Description of the issue:
The Nuclear app does not support the music player in the top menu bar on Mac.

@T0Pat T0Pat added the bug This issue identifies a bug in Nuclear. label Jul 18, 2024
@nukeop nukeop added feature request This is a request for the addition of some feature. and removed bug This issue identifies a bug in Nuclear. labels Jul 18, 2024
@nukeop
Copy link
Owner

nukeop commented Jul 18, 2024

Do you mean this thing that appears when you click the icon with black and white bars?

image

@T0Pat
Copy link
Author

T0Pat commented Jul 19, 2024

Yes, although from my perspective, it looks like this.
Screenshot 2024-07-18 at 8 42 07 PM

@nukeop nukeop assigned nukeop and unassigned nukeop Oct 20, 2024
@gr33nMari0
Copy link

Hey there - wanted to follow up on this one and try and fix the media controls for macOS.

As of latest Nuclear release (0.6.39), on macOS Sequoia 15.0, the media player does not display Album art, current playback status, timestamps, or previous/next track controls. On my end, this is how it looks:

System Preferences 2024-10-20 18 58 18

Ideally, when playing a song in Nuclear, the macOS playback widget should act the same as when Spotify is playing audio in it’s desktop app:

Discord 2024-10-20 19 02 35

This behaviour is also visible through the YouTube Web player, in the Safari browser (noting that YouTube has injected a skip forward/backward 30sec control:

Safari 2024-10-20 19 02 58

From an initial read, it seems that the HTML Media Session API might be able to handle this entirely in the frontend side of the app, but there may be an electron-server-side part which can handle a direct system api interaction. I think that there is a good chance the system-specific behaviour can be bypassed by just using the standard browser/html media session API which would then provide support on all platforms, as Windows and Linux also have similar widgets for active media, which also support web audio sources such as YouTube or Spotify Web. This would be easier to test as well as there isn’t much of a defined testing process for the electron server code.

If we do need to focus on an electron level system audio handler, then a more modern version of electron-media-service (https://www.npmjs.com/package/electron-media-service) - if one exists - would be the way to go. I just think it would be less than ideal to implement OS-specific system API calls for media handling as this stifles maintainability.

Happy to be assigned the issue!

@gr33nMari0
Copy link

More on the Media Session API:

"The MediaMetadata interface lets a website provide rich metadata to the platform UI for media that is playing. This metadata includes the title, artist (creator) name, album (collection), artwork, and chapter information."

And most usefully to Nuclear:
"The platform can show this metadata in media centers, notifications, device lock screens, and so on."

For the windows devices, the Media Session API would provide a display like this:
image

And - Hardware media keys are supported through Media Session! (Minor concern: how will this impact existing hardware media controls as currently implemented?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request This is a request for the addition of some feature.
Projects
None yet
Development

No branches or pull requests

3 participants