-
Notifications
You must be signed in to change notification settings - Fork 260
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
WIP: Optional media player auto-resume, central management of device call-state responses #1318
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -96,16 +96,32 @@ var Plugin = GObject.registerClass({ | |
} | ||
|
||
/** | ||
* Restore volume, microphone and media player state (if changed), making | ||
* sure to unpause before raising volume. | ||
* Restore volume and microphone, plus media player state | ||
* (if we changed it and restore is enabled). | ||
* | ||
* If we're going to auto-resume, make sure to do that first | ||
* before raising volume. | ||
* Otherwise, still raise the volume (so the user can unpause). | ||
* | ||
* TODO: there's a possibility we might revert a media/mixer state set for | ||
* another device. | ||
*/ | ||
_restoreMediaState() { | ||
// Media Playback | ||
if (this._mpris) | ||
this._mpris.unpauseAll(); | ||
if (this._mpris) { | ||
if (this.settings.get_boolean('ended-resume')) { | ||
this._mpris.unpauseAll(); | ||
} else { | ||
/* Even if resume is disabled, we still need to clear | ||
* the list of which players we're holding paused | ||
* | ||
* TODO: This potentially worsens the multi-device | ||
* problem, since we may be erasing the player | ||
* list when another device still needs it. | ||
Comment on lines
+118
to
+120
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As the comment notes, this potentially exacerbates an existing problem that can come up when multiple devices are paired to the local machine. Solving that is beyond the scope of this change. (The problem is that local player state is global to the extension (or should be), but the actions to manage that state are implemented in the per-device plugins. We may need to take a page from So, instead of the current logic here, something like:
Managing audio volumes is probably an even trickier juggling act, since the states there aren't as simple as "paused" and "not paused" and multiple devices' requests will have more complex interactions. Also, open question: If a device disconnects from GSConnect, is its request deleted immediately? Deleted after a grace period (to see if it reconnects)? Deleted only if there are no other requests? Deleted only when there are other requests? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This sounds pretty reasonable. As for the last question I don't really know if there's a good answer, but the best answer would probably be to err on the side of leaving the media in its current state (ie. paused). Likewise, if the playback is changed externally that should probably clear any pending "inhibitors" and assume the user has taken the steering wheel. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @andyholmes That makes sense. So, if a device drops off unexpectedly, it still gets removed from the inhibit list immediately. (Because we have no idea what its call state is anymore, even if it comes back.) Buuuut, playback doesn't resume even if it's the last device on the list. At which point, since the list is empty, the MPRIS backend still throws away its stored player state and washes its hands of the whole thing, leaving it to the user to do as they please. (Basically, returning to its default state of not managing any player controls, where it will stay until a new call event comes in and prompts it to start the pause-and-monitor cycle over again.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could post a notification to the Shell, too, when a device drops off unexpectedly. (Only in the specific case that it had an active call in progress and its inhibits were dropped. Otherwise, we're just pestering the user with irrelevancies.) That way, they'll know why the auto resume "didn't work". (And hopefully not generate any new bug reports.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, I'd lean towards no notification myself, but I see the argument for it. I'll leave that to you :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @andyholmes So, to monitor devices with active pause tokens for unexpected disconnects from the MPRIS backend code, is a ...Hrm, actually, that wouldn't work, I'd need to know if it'd disconnected and reconnected at any point as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, wait, now I see it. The telephony plugin's There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You could also use the pattern from the component code, with a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @andyholmes I ended up concluding that explicit ref/token counting didn't really buy me anything. I wanted to keep a central list (a
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good, I await your commit so I can have a good look :) |
||
*/ | ||
this._mpris.clearPaused(); | ||
} | ||
} | ||
|
||
// Mixer Volume | ||
if (this._mixer) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops. Hadn't intended to leave these in, but maybe that's not the worst thing.