feat: add seek AppleScript command and now-playing notification broad… - #333
feat: add seek AppleScript command and now-playing notification broad…#333WGlegola wants to merge 1 commit into
Conversation
|
Related boring.notch pr: |
d0e5ae7 to
bce27fc
Compare
|
TheBoredTeam/boring.notch#1362 (comment) Action for making working connection have to be taken from this side. If this solution is accepted prerequisite for merging boring.notch side of implementation would be fulfilled. Afaik this method is standard on macos. If im not mistaken this is how spotify and similar comunicate their status. Also seems more straight forward than #210. |
…cast Adds a 'seek' AppleScript command (jump to a position in seconds) and a NowPlayingBroadcaster that posts a com.sertacozercan.Kaset.playerInfo distributed notification on playback/track/like changes, so external now-playing surfaces (e.g. boring.notch's Kaset source) can refresh without polling. Updates the AppleScript docs.
bce27fc to
2449674
Compare
|
🔥 Wanted to do this and went through the open issues and found you had already done it. Hope it gets merged! |
@sozercan , so now there are 2 people who hopes this get merged 😃 . |
Description
Adds the AppleScript + notification plumbing that lets external "now playing"
surfaces — menu-bar widgets, Stream Deck, and notch apps such as boring.notch —
mirror and control Kaset playback reactively, without polling the app.
Two additions:
seekAppleScript command — jump to an absolute position (in seconds) in the current track, e.g.tell application "Kaset" to seek 90. This completes the transport surface (alongside the existing play / pause / next / previous /set volumecommands) so an external scrubber can drive playback position.NowPlayingBroadcaster— posts a lightweight distributed notification (com.sertacozercan.Kaset.playerInfo) whenever discrete playback state changes (current track, play/pause, like status, shuffle, repeat). Listeners refresh by calling the existingget player infocommand instead of polling on a timer. High-frequencyprogressandvolumeare intentionally excluded so the notification doesn't fire continuously during playback or volume drags.Both are read/control affordances over already-exposed state; no playback or auth
behavior changes.
Type of Change
Related Issues
Enables external now-playing integrations such as TheBoredTeam/boring.notch#1167
("Kaset as a music source"). No Kaset-side issue.
Changes Made
SeekCommand(KasetSeekCommand)NSScriptCommand→PlayerService.seek(to:); coercion-fails with a clear error on a non-numeric argument.seekcommand (codeKastseek,realdirect-parameter) inKaset.sdef.NowPlayingBroadcaster(inServices/Player/, besideNowPlayingManager):observes
PlayerServiceviawithObservationTrackingand posts a bundle-id-prefixed distributed notification on discrete state changes. Wired up once inMainWindow's.task.seek(+ shell example) and the notification contract ("Now Playing Notifications") indocs/applescript.md.SeekCommand(nil-player + invalid-arg); pin the cross-processget player infocontract keys consumed by external surfaces (position,duration,artworkURL); pin the broadcaster'snotificationNamestring.Testing
swift test --skip KasetUITests— 1551 tests, 132 suites)Manual verification against a live build:
get player inforeturns the full state contract;seek 30/seek 90jump the position exactly;like tracktogglesliked↔none;toggle shuffle,cycle repeat,playpause,next trackall work.Checklist
swiftlint --strict && swiftformat .(0 violations, 0 formatting changes)docs/applescript.md)progress/volume)Additional Notes
like trackcommand — no change is required here for liking. This PR adds the reactive refresh signal (so an external heart updates promptly instead of on a poll) and theseektransport command.userInfo(the App Sandbox strips it from a sandboxed sender) and uses a bundle-id-prefixed name so the sandbox permits posting; listeners read full state viaget player info. It is a bare, change-only trigger, so consumers pollget player infofor the initial state and for position/volume.