video/out/w32_common: add --focus-on support for Windows#18062
video/out/w32_common: add --focus-on support for Windows#18062CrendKing wants to merge 2 commits into
Conversation
|
In #17675 I add a VO flag for file changes, it could be reused for |
|
Thank you for letting me know! If I understand you correctly, all I need to do is to handle Also, shouldn't this flag be also used in X11 and Mac versions? |
|
No you would need a new |
This is exactly the splash window, it will show window with mpv logo until the file is open. |
|
I agree, but since |
I just made a commit to add a new |
|
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. |
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.
|
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 |
|
I don't know what's required to flash mpv icon and if that's 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... |
That's just what the If you guys think we should not support the |
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=immediatefor 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=opencase.If user still moves to other apps when ytdl_hook resolves, to make mpv automatically foreground when playback starts,
--force-window=allis needed. However, if I understand correctly, this value meansSetForegroundWindowneeds 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 triedvo_w32_config, but it seems if the next file has the same width and height as previous, the window doesn't "reconfig", thusvo_w32_configis not called. There doesn't seem to be a function that is guaranteed to be called for every new file. I could try handling theVOCTRL_UPDATE_WINDOW_TITLErequest invo_w32_control, but I feel it might have false positive. Any suggestion?