Honor user video shortcuts in fullscreen video window#11398
Merged
Conversation
The fullscreen window's KeyDown handler hardcoded Right/Left to ±2 sec and Up/Down to ±2 volume, running before its local shortcut manager. The local shortcut manager also only knew about two commands (toggle fullscreen, show media info), so even if the order were swapped, the user's "1 sec forward", "100 ms back", etc. bindings had no path to fire while fullscreen was open. Two changes: * MainViewModel.VideoFullScreen now builds an extraBindings list of the relevant video commands (jump back/forward 100 ms / 500 ms / 1 sec / one frame / custom 1 / custom 2, play, pause, toggle play-pause x2, toggle brightness), each paired with its configured keys from Se.Settings.Shortcuts, and passes it to FullScreenVideoWindow. The commands themselves operate on GetVideoPlayerControl(), which returns the fullscreen player while fullscreen is open, so no per-fullscreen variants are needed. * FullScreenVideoWindow accepts the new extraBindings parameter and registers each into its local shortcut manager. The KeyDown handler is reordered: Esc/F11 still always close, user shortcuts run next, and the Space/Right/Left/Up/Down hardcoded handlers are demoted to fallbacks for users who haven't bound those keys. Volume Up/Down stay hardcoded because there are no Volume RelayCommands in the view model. Fixes #11392 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
FullScreenVideoWindow'sKeyDownhandler hardcoded these keys before its local shortcut manager, and the local shortcut manager only knew about two commands (toggle fullscreen, show media info). Reordering alone wasn't enough — the user-configured shortcuts had no path to fire.Changes
MainViewModel.VideoFullScreennow builds anextraBindingslist of the relevant video commands and passes it toFullScreenVideoWindow. The commands themselves operate onGetVideoPlayerControl(), which already returns_fullScreenVideoPlayerControlwhile fullscreen is open, so no per-fullscreen variants are needed.Video100Ms{Back,Forward},Video500Ms{Back,Forward},VideoOneSecond{Back,Forward},VideoOneFrame{Back,Forward},VideoMoveCustom1{Back,Forward},VideoMoveCustom2{Back,Forward},Play,Pause,TogglePlayPause,TogglePlayPause2,VideoToggleBrightness.FullScreenVideoWindowgains an optionalextraBindingsconstructor parameter, registers each into the local shortcut manager, and theKeyDownhandler is reordered:Space/Right/Left/Up/Down— fallbacks only when no user binding matched.RelayCommands in the view model; the fullscreen defaults are the only keyboard-volume path.Test plan
TogglePlayPausebinding).Show Media Informationshortcut still opens with the fullscreen window as owner.🤖 Generated with Claude Code