Skip to content

video/out/w32_common: add --focus-on support for Windows#18062

Open
CrendKing wants to merge 2 commits into
mpv-player:masterfrom
CrendKing:win32-focus-on
Open

video/out/w32_common: add --focus-on support for Windows#18062
CrendKing wants to merge 2 commits into
mpv-player:masterfrom
CrendKing:win32-focus-on

Conversation

@CrendKing
Copy link
Copy Markdown
Contributor

Background: I use the pseudo GUI mode. If I give mpv a network source (like a YouTube video), ytdl_hook will take a while to resolve the video URL, and mpv doesn't show any window until the video is ready to be output, due to the default --force-window=yes. In the meantime, if I click any other window, when mpv's main window eventually shows, it is in background. I had to write a AutoHotkey script to wait for the mpv window to be created then bring it to foreground. Then I saw c0ef689, thought I might be able to do the same for Windows support.

Windows has focus stealing prevention mechanism. If a user launches an app, and that app doesn't immediately create a window and show it in foreground, it will lose the ability to do that by itself later. That's why many large apps (such as Visual Studio or Photoshop) that takes a while to initialize come with splash window nowadays: it secures the seat to bring the real main window foreground later.

Since mpv currently lacks a proper splash window, I think recommending --force-window=immediate for those who need this launch-foreground-feature is sound. It makes the main window immediately appear and give user hint "you should focus on this because something is about to happen". It serves the default --force-window=open case.

If user still moves to other apps when ytdl_hook resolves, to make mpv automatically foreground when playback starts, --force-window=all is needed. However, if I understand correctly, this value means SetForegroundWindow needs to be called when every new file is started. I saw in X11 and Mac implementations that they put equivalent API in the vo's "reconfig" entry point. I tried vo_w32_config, but it seems if the next file has the same width and height as previous, the window doesn't "reconfig", thus vo_w32_config is not called. There doesn't seem to be a function that is guaranteed to be called for every new file. I could try handling the VOCTRL_UPDATE_WINDOW_TITLE request in vo_w32_control, but I feel it might have false positive. Any suggestion?

@guidocella
Copy link
Copy Markdown
Contributor

In #17675 I add a VO flag for file changes, it could be reused for --focus-on.

@CrendKing
Copy link
Copy Markdown
Contributor Author

CrendKing commented Jun 2, 2026

Thank you for letting me know! If I understand you correctly, all I need to do is to handle VOCTRL_SET_PANSCAN in gui_thread_control and SetForegroundWindow there when --force-window=all?

Also, shouldn't this flag be also used in X11 and Mac versions?

@guidocella
Copy link
Copy Markdown
Contributor

No you would need a new VOCTRL that we can send when changing_file is true.

@kasper93
Copy link
Copy Markdown
Member

kasper93 commented Jun 2, 2026

Since mpv currently lacks a proper splash window, I think recommending --force-window=immediate

This is exactly the splash window, it will show window with mpv logo until the file is open.

@CrendKing
Copy link
Copy Markdown
Contributor Author

I agree, but since --force-window=immediate is not the default, I'm adding that text to make user aware how to use the feature reliably.

@CrendKing
Copy link
Copy Markdown
Contributor Author

No you would need a new VOCTRL that we can send when changing_file is true.

I just made a commit to add a new VOCTRL_FILE_CHANGE and use it in w32_common. Hope I catch your means. It would still need your PR to go in and send the control request from the vo though.

@guidocella
Copy link
Copy Markdown
Contributor

guidocella commented Jun 2, 2026

Yeah that's what I was thinking. I will modify my PR to send this VOCTRL. The current way is incorrect because it will gain focus on any reconfig, so also when rotating and overriding the aspect ratio, other than not being triggered when the new file has the same dimensions and properties.

guidocella added a commit to guidocella/mpv that referenced this pull request Jun 2, 2026
The last commit added logic to handle file changes in the VO. This can
be reused in mpv-player#18062 and future features, so send a dedicated VOCTRL for
file changes.
@kasper93
Copy link
Copy Markdown
Member

kasper93 commented Jun 2, 2026

VO doesn't have to know that the file change. VO doesn't even know what "a file" is. It's not VO job to care about files. What you can do is add VOCTRL to set focus. And call it when needed. Other VO should react to this too.

However, I'm not sure you can even do that. Window cannot be focused, if it would otherwise steal focus from other window. So even if you call it on file switching, it will do nothing likely.

@CrendKing
Copy link
Copy Markdown
Contributor Author

CrendKing commented Jun 2, 2026

VO doesn't have to know that the file change. VO doesn't even know what "a file" is. It's not VO job to care about files. What you can do is add VOCTRL to set focus. And call it when needed. Other VO should react to this too.

However, I'm not sure you can even do that. Window cannot be focused, if it would otherwise steal focus from other window. So even if you call it on file switching, it will do nothing likely.

I was testing this change locally, and I swear it worked: play a 10 second video, switch to different app right at beginning. When video changes, mpv magically comes foreground.

Turns out, AutoHotkey changes the foreground lock timeout to 0, even though their changelog states they no longer do the override, and I have AutoHotkey autorun at boot. 0 timeout seems disable the post-launch focus stealing mechanism (but launch-time prevention is still there).

Assuming most users don't override the timeout or run AutoHotkey, the file-change focus will not work on Windows. But do you think we should still do the SetForegroundWindow attempt, so user can at least get the taskbar icon flashed to indicate file change? Without the call, there is no visual notification. Then we document the specific behavior for Windows.

@kasper93
Copy link
Copy Markdown
Member

kasper93 commented Jun 2, 2026

I don't know what's required to flash mpv icon and if that's SetForegroundWindow, but yes it would be ok to do such thing. But please design it with correct module separation. VO gets "focus" request, from player core when such thing should trigger.

Also it is possible to bring window to front, but without giving it focus. Though, I don't see much usecase for any of this. If mpv is playing in background, why would you want to flash it to front...

@CrendKing
Copy link
Copy Markdown
Contributor Author

CrendKing commented Jun 2, 2026

If mpv is playing in background, why would you want to flash it to front...

That's just what the --focus-on=all description says: make it the front most window on open and new file events. It means if it is in background, and new file event happens, it should be brought to front most, right? Since we can't actual do it, flash it seems the next best option to serve the same purpose (i.e. give user awareness that a new file just loaded).

If you guys think we should not support the all value on Windows because we can't do it properly, just let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants