© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
The relevant bit from the regulation, as quoted in the spec, is "Provide a means to actively inform the user of the increased sound pressure ... Any means used shall be acknowledged by the user". Tapping a button in a dialog is acknowledgement by the user. Toggling a settings switch, ahead of time, would arguably be acknowledgement by the user (I'd want to check with a lawyer first). But maybe or maybe not noticing that the volume gauge is a different color is not acknowledgement by the user.
"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.
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.
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.
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.