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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1544543 Title: org.mpris.MediaPlayer2.MediaHub player is exposed at startup, making the indicator show a player that it's not fully functional To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1544543/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
