touch-packages team mailing list archive

[Michał Sawicz <michal.sawicz@xxxxxxxxxxxxx>]

W dniu 06.12.2015 o 19:59, Matthew Paul Thomas pisze:
> "What's more, it's not the dialog, nor the shell, that decides to pause
> the video or not. It's the media player that does, because it's been
> unfocused. Do you believe that some dialogs should change focus, some
> shouldn't?"
> 
> I'd happily answer in detail, but that issue seems to be four steps
> removed from fixing this bug. First, focus and layering are not the same
> thing. Focus stealing prevention is important, but on phones Unity might
> need to layer dialogs in front even when denying them focus, because --
> unlike on PCs -- it can't rely on the Launcher to show you that they've
> opened. All my examples assume the dialogs will be in front, but not
> necessarily focused.

What's the difference between a focused and an unfocused dialog, when
it's in front in both cases?

> Second, even if being unfocused was a reliable indicator of being in the
> background, that would be a highly questionable reason to pause video.
> For example, it would be annoying to pause music merely because the
> player is in the background -- but currently, 40% of music listening is
> done on YouTube, and is therefore video.

We don't support such a use case on the phone today, and while I'd argue
there's a need for an app that would do that for you (ignore the video
stream to save bandwidth and battery), I do get we need to think of such
a use case. Don't have a good answer how to behave here, though.

> Third, regardless of whether being in the background is a good reason to
> pause video, individual media-playing apps seem like the wrong place to
> make that decision. For example, a phone call should pause video, and
> pause music, and mute any other multimedia audio, in every app, when the
> call rings. Does that mean every media-playing app should contain code
> for pausing on phone calls? Of course not; app developers would usually
> not know, not remember, or not bother. It's a job for the media
> frameworks, not the apps.

Indeed, and that's how it works today, all multimedia streams are paused
when a stream plays in the "ringtone" role, such as an incoming call.
Whether the same should apply for incoming SMS is questionable, so it's
not as easy as "when there's a ringtone, pause", so we'll need more
smarts here still.

> And fourth, even if apps were responsible for pausing video, I don't
> think that pausing should have any effect on the volume warning dialog.
> I think that's the root problem, and the reason for my spec change
> above: as long as the dialog is up, audio pausing shouldn't change the
> active output role and therefore shouldn't dismiss the dialog.

Full agreement here.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mediaplayer-app in Ubuntu.
https://bugs.launchpad.net/bugs/1504065

Title:
  Cannot play videos when a wired headphone is connected

Status in Canonical System Image:
  Confirmed
Status in The Sound Menu:
  New
Status in mediaplayer-app package in Ubuntu:
  Confirmed
Status in unity8 package in Ubuntu:
  Confirmed

Bug description:
  When having a wired headset connected to the device, video playback
  keeps on being paused as soon as playback is started. Looks like some
  snap-decision notification is shown, but it's too short time to read
  what it actually says because it disappears again when the playback
  stops again.

  <https://wiki.ubuntu.com/Sound#limits>: "So that both buttons do what
  you expect and the dialog does not disappear unexpectedly, any role
  change should be postponed as long as the dialog is up."

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1504065/+subscriptions