Comment 17 for bug 1504065

W dniu 03.12.2015 o 12:15, Matthew Paul Thomas pisze:
> By "no way of discerning" you mean it's a matter of taste, right?

No, actually, no means for the originator of the dialog to communicate
whether the desire is to pause or not. Not saying it's impossible to
add, just more throw-away work in soon-to-be reimplemented
notification/dialog area.

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?

> For
> example, you would choose to pause video for the high-volume warning
> dialog, whereas I would not. And even if that was a good reason to pause
> video, it would be much less of a good reason to pause music, which
> might have caused the same dialog to appear.

Sure, music doesn't pause when the app is unfocused, so we're good there.

> Earlier this year, for reasons too comical to explain here, I had to collect examples of dialogs that don't belong to a particular app. (Some of these are currently jury-rigged as snap decisions, others not implemented in Ubuntu Touch at all yet.) It's not necessarily a good idea to let dialogs choose whether to pause video behind them or not. But *if* they could do that, this is what I'd choose for the examples I collected:
> - high volume warning -- don't pause
> - Wi-Fi authentication -- pause
> - "Connect to Hidden Network" -- pause
> - "Wi-Fi Available" -- pause
> - proxy re-authentication -- pause
> - choosing what to do with inserted media -- don't pause
> - critically low battery -- pause
> - disk space/health warning -- pause
> - error reporting -- don't pause
> - incoming call -- pause
>
> So if it's better overall to have a single behavior for every dialog, I
> guess that behavior should be pausing. But the larger the screen size,
> the less sense that will make.

Here, too, the question is what should the media player app do when it's
unfocused - some would argue they'd want the video continue to play even
on a phone when they've switched to a different app. Certainly true on
the desktop.

> And regardless of those answers for
> video, my answer would be "don't pause" for all of them with audio.

Agreed.

> All that aside, if you say the dialog should pause video, well, it's
> already doing that, so the problem remains unsolved. We need to make
> sure the dialog stays visible *despite* the video pausing. Given that
> there will always be more than one audio role, role switching will
> always be a possibility, so we seem to have two options. The first is to
> switch the role as usual, but persist the alert referring to a role that
> the volume buttons are no longer controlling; but that would be
> incoherent. The other is to delay any role change for as long as the
> dialog is up. Specification updated.
> <https://wiki.ubuntu.com/Sound?action=diff&rev2=163&rev1=162>

Works for me.