Comment 4 for bug 1544543

Yes thanks for that clarification as I did mean to say the control portion of indicator-sound, not the entire indicator itself.

Can you cite an example where a system component might act as an app? I want to make sure that this isn't only a hypothetical situation. Also, I'm not sure how the second part of your 2nd paragraph is relevant for this bug. That seems like one or more separate bugs to solve if a system component is showing up undesirably in those other situations.

The example scenario that you give isn't a good one to demonstrate the current bug only because Oxide and media-hub integration aren't fully implemented and usually requires special handling when compared to the average application. The main case that's not currently clear in my mind is what do we want to display in indicator-sound on a fresh boot of the phone. If the controls are not hidden, then what should it look like and how should it behave?

A second thing to solve will be the case when all media applications have been closed by the user essentially getting back to the first boot state. All media-hub sessions have been closed so any track metadata and the playlist associated with that session have been lost. So we can't simply keep allowing the MPRIS controls to control the last media-hub session because it's no longer valid. So do we hide the controls? If not, what else can we do?