win32: remove SC_RESTORE handling

[kasper93]

No description provided.

[kasper93]

@na-na-hi do you know where this would be needed? I couldn't reproduce on my end. Maybe it was FSE mode that is no longer with us.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[na-na-hi]

do you know where this would be needed?

After a maximized window is put in fullscreen, when you press win+down, it exits fullscreen in a maximized state.

[kasper93]

do you know where this would be needed?

After a maximized window is put in fullscreen, when you press win+down, it exits fullscreen in a maximized state.

I see, but what is expected behavior in this case? Shouldn't it exit fullscreen? Same as win+down goes from maximized to windowed first.

[na-na-hi]

I see, but what is expected behavior in this case? Shouldn't it exit fullscreen?

It does. As I already said, currently win+down in fullscreen exits fullscreen if window-maximized=yes. With this PR, it instead restores to the unmaximized size while still retaining the fullscreen state, so the window has no titlebar and cannot be resized or dragged.

[kasper93]

I see, but what is expected behavior in this case? Shouldn't it exit fullscreen?

It does. As I already said, currently win+down in fullscreen exits fullscreen if window-maximized=yes.

But if it is not maximized it minimize instead. Is this expected to you?

I found dozen other bugs when testing this again, so we can postpone this discussion. I only wanted to know if this is expected that fs=yes window-maximized=no minimizes the window instead of restoring it to window state.

[na-na-hi]

But if it is not maximized it minimize instead. Is this expected to you?

win+down on a non-maximized window normally minimizes it. Technically fs=yes window-maximized=no is non-maximized. MPC-HC does the same thing, just in a more buggy way. VLC does nothing with win+down on fullscreen.

I don't think there is any expected behavior in this case. As long as it does not leave the window in a buggy state it should be fine.

[kasper93]

@na-na-hi: Could you help testing this one? I had it long in the backlog. Let me know of any undesirable behavior, maybe we will manage to get this in.

[na-na-hi]

The latest version still has this issue: #16127 (comment)

[kasper93]

The latest version still has this issue: #16127 (comment)

Should be fine now, could you try again?

[na-na-hi]

Should be fine now, could you try again?

That issue is fixed but there is a new one: maximize, fullscreen, then print the value of window-maximized shows no, when it should be yes.

[kasper93]

Should be fine now, could you try again?

That issue is fixed but there is a new one: maximize, fullscreen, then print the value of window-maximized shows no, when it should be yes.

Updated. One thing I really wanted to have is to keep window-maximized and window-minimized state actually reflect the window state. And apparently in fullscreen we need to restore window to normal, to avoid (external) window restore to do bad things to us. So, now I made an exception that window_maximized = w32->pending_maximize && w32->current_fs, so when we have pending maximize (i.e. we will go back to maximize after fullscreen) window-maximized will report yes.

Hopefully, this doesn't cause domino effect in some other parts. But when it really matters, I tried to use IsMaximized() to get real state.

[kasper93]

Will merge if there are no more comments.

[na-na-hi]

Setting geometry when only x or y is changed without w or h changing does not work.

Setting geometry wxh without specifying x/y and where w or h is larger than screen size results in window being partly off screen. Window size is eventually confined to screen size but x/y are not.

[kasper93]

Setting geometry when only x or y is changed without w or h changing does not work.

Fixed.

Setting geometry wxh without specifying x/y and where w or h is larger than screen size results in window being partly off screen. Window size is eventually confined to screen size but x/y are not.

Would you prefer to contain whole window in working area? Or only top-left corner? What if user moves 90% of window outside of screen? Should we on resize bring it fully in view?

[kasper93]

Setting geometry wxh without specifying x/y and where w or h is larger than screen size results in window being partly off screen. Window size is eventually confined to screen size but x/y are not.

I've added explicit size constrain also for geometry. Let me know what do you think. Previously it was constrained by Windows in this case.

[kasper93]

@na-na-hi: have you had a chance to retest this?

[na-na-hi]

Would you prefer to contain whole window in working area? Or only top-left corner? What if user moves 90% of window outside of screen? Should we on resize bring it fully in view?

Since the geometry is constrained, I think it should be contained to the working area if geometry is set without x/y, but should obey x/y if they are specified. Although on other platforms the window size is not constrained, so I am not sure if Windows should also do the same.

Currently if I increase window-scale to larger than display size then the y is constrained to inside screen, but not x. But if I set with geometry them both x and y are not constrained to inside screen.

[kasper93]

Since the geometry is constrained, I think it should be contained to the working area if geometry is set without x/y, but should obey x/y if they are specified.

This is controlled with --force-window-position. If you set this to yes, it will respect geometry position.

Although on other platforms the window size is not constrained, so I am not sure if Windows should also do the same.

Windows itself limits window size to display size. This is not taking into account taskbar (workspace area) and have other issues, so we limit size correctly ourselves. This was also done previously, just in arguably more buggy way.

Currently if I increase window-scale to larger than display size then the y is constrained to inside screen, but not x. But if I set with geometry them both x and y are not constrained to inside screen.

I will check that, but basically what happens is Windows always moves window so the y >= 0. But as with everything, when set directly the x/y it will not complain.

I will try to make it better, but in some cases I'm not sure how it actually should behave, because both outcomes seems ok, just different.

[kasper93]

Currently if I increase window-scale to larger than display size then the y is constrained to inside screen, but not x. But if I set with geometry them both x and y are not constrained to inside screen.

Made it consistent in both case.

Please test. I think it works mostly ok now. I have some ideas like adding option to prevent window going out of the working space, but will do it in separate PR, as it is new feature.