Conversation
|
|
src/cascadia/TerminalApp/Pane.cpp
Outdated
| winrt::Windows::Foundation::Uri uri{ sounds.GetAt(rand() % sounds.Size()) }; | ||
| auto source{ winrt::Windows::Media::Core::MediaSource::CreateFromUri(uri) }; | ||
| auto item{ winrt::Windows::Media::Playback::MediaPlaybackItem(source) }; | ||
| p.Source(item); | ||
| p.Play(); |
There was a problem hiding this comment.
What happens if the URI points to a video file or stream?
There was a problem hiding this comment.
omfg it's great.
Say you had a file that was no.mp4. If you set the path to "bellSound": "%~%\\Downloads\\memes\\no.mp4", then it'll just play the entirety of the audio of the mp4 file. It's great. If you emit another bell in the middle, then it'll just start it over.
There's a lot of possibilities here.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Somehow, this also causes an exception on teardown north of `Windows.Media.MediaControl.dll!AudioStateMonitorImpl::remove_SoundLevelChanged()`, which is in OS code somewhere. Not sure there's anything we can actually do about this. There are piles of bugs on that function in the OS repo. I think we're going to have to just end up avoiding this entirely.
This reverts commit fb1ed58.
This comment has been minimized.
This comment has been minimized.
| profile->_Hidden = _Hidden; | ||
| profile->_TabColor = _TabColor; | ||
| profile->_Padding = _Padding; | ||
|
|
There was a problem hiding this comment.
this random newline seems unnecessary but meh haha
There was a problem hiding this comment.
that actually seems to be the case with most of this file.
src/cascadia/TerminalApp/Pane.cpp
Outdated
| auto source{ winrt::Windows::Media::Core::MediaSource::CreateFromUri(uri) }; | ||
| auto item{ winrt::Windows::Media::Playback::MediaPlaybackItem(source) }; |
There was a problem hiding this comment.
| auto source{ winrt::Windows::Media::Core::MediaSource::CreateFromUri(uri) }; | |
| auto item{ winrt::Windows::Media::Playback::MediaPlaybackItem(source) }; | |
| const auto source{ winrt::Windows::Media::Core::MediaSource::CreateFromUri(uri) }; | |
| const auto item{ winrt::Windows::Media::Playback::MediaPlaybackItem(source) }; |
nit
|
Mind filing a follow-up issue for an update to the SUI? |
Co-authored-by: Carlos Zamora <[email protected]>
|
Hello @zadjii-msft! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
| val.push_back(trait.FromJson(element)); | ||
| } | ||
| } | ||
| else |
There was a problem hiding this comment.
note to self: this is the place I should just check for null and skip
Sorry for combining two fixes in one PR. I can separate if need be. * [x] Closes #12276: - `"bellSound": null` didn't work. This one was easier, and is atomically in bcc2ca0. Basically, we would deserialize that as an array with a single empty string in it, which we'd try to then play. I think it's more idomatic to have that deserialized as an empty array, which correctly falls back to playing the default sound. * [x] Closes #12258: - This one is the majority of the rest of the PR. If you leave the MediaPlayer open, then the media keys will _affect the Terminal_. More importantly, once the bell sounds, they'd replay the bell, which is insane. So the fix is to re-create the media player when we need it. We do this per-pane for simpler lifetime tracking. I'm not worried about the overhead of creating a mediaplayer here, since we're already throttling bells. * Originally added in #11511 * [x] Tested manually - Use [`no.mp4`](https://www.youtube.com/watch?v=x2w9TyCv2gk) for this since that's like, 17s long - Checked that closing panes / the terminal while a bell was playing didn't crash - Playing a bunch of bells at once works - closing a pane stops the bell it's playing - once the bell stops, the media keys went back to working for Spotify * [x] I work here
|
🎉 Handy links: |
|
As noted in #11511 (comment). Missed in #13035
As noted in #11511 (comment). Missed in #13035 (cherry picked from commit 86dfefa) Service-Card-Id: 83891742 Service-Version: 1.14
As noted in #11511 (comment). Missed in #13035 (cherry picked from commit 86dfefa) Service-Card-Id: 83891743 Service-Version: 1.15

Summary of the Pull Request
Adds a per-profile setting for setting the audio sound for the bell. The setting is
bellSound, it accepts a path. We'll use the file at that path as the sound for the bell. If it doesn't exist, then oh well, so sound for you.It'll also secretly accept an array of paths. If you provide an array, it will pick one at random.
PR Checklist
Validation Steps Performed
I'm not suggesting that anyone go to this post and download a zip full of
honk.mp3s. I'm definitely not suggesting you add it to your settings likeNo, don't do that.
honk-001.mp4
MediaPlayerper terminal, rather than one per pane