osc.lua: fix window controls showing in fullscreen

[kasper93]

No description provided.

[na-na-hi]

I think the expectation of fullscreen is that there is no titlebar. The OSC window control is to act as client side decoration in windowed mode, which makes no sense in fullscreen.

[kasper93]

I think the expectation of fullscreen is that there is no titlebar. The OSC window control is to act as client side decoration in windowed mode, which makes no sense in fullscreen.

What expectations are we basing this on? Most applications have both windowed controls, often permanently visible and fullscreen controls shown on hover. Fullscreen mode should be unobstructed, but still functional and able to navigate with mouse if user wants.

I find windowed controls, whether client side or otherwise, useful for users. In mpv case there is no really a difference if in windowed or fullscreen state. Both states are essentially the same, with the difference of window size. I mean we always displaying video, there is no functional difference in which mode we are.

If we compare to arguably the most popular media players, like youtube or netflix they both have top bar visible in fullscreen. Since those are nested players, there is no "close" button, but similar top bar (additionally to bottom controls) is present and often with ability to exit fullscren.

VLC has top bar with some buttons. Older MPC-HC doesn't have anything, but this is very Windows 95 style application, where whole window is heavy in win32/mfc controls and actual video area is tiny, and fullscreen doesn't have decorations. MPC-BE has window controls in the top right corner.

So, to me it looks like general trend is to utilize the top area for some controls. Additionally default 0.5s of hide timeout in mpv is very quick to hide any controls, so they are not obstructing any view more than they have to.

Since this is easily accessible, I won't force it, but I genuinely think it's useful and wouldn't cause users to not like it.

Also note that there is currently a bug, where window controls are based on title-bar and border options, while also in fullscreen, and since many users actually disable window decorations, because they are unnecessary for mpv in practice, the window controls actually are enabled by extension also in fullscreen mode and no one really complains about it.

[na-na-hi]

Most applications have both windowed controls, often permanently visible and fullscreen controls shown on hover. Fullscreen mode should be unobstructed, but still functional and able to navigate with mouse if user wants.

Fullscreen controls that are there to show functional elements of the applications. Not window decorations, because they achieve window management functions rather than as an interface for application functionality.

If we compare to arguably the most popular media players, like youtube or netflix they both have top bar visible in fullscreen. Since those are nested players, there is no "close" button, but similar top bar (additionally to bottom controls) is present and often with ability to exit fullscren.

In YouTube, the top bar shows video title because it is not shown in the bottom controls, and the fullscreen toggle is at bottom right. There is also no functional controls on the top bar. In mpv, the top bar does not provide addition useful information like YouTube player does because the title is already shown in the bottom bar, and the fullscreen toggle is also at the bottom bar, not the top bar.

VLC has top bar with some buttons.

The newest version of VLC does not have top bar at fullscreen by default, at least on Windows where I tested.

Older MPC-HC doesn't have anything, but this is very Windows 95 style application, where whole window is heavy in win32/mfc controls and actual video area is tiny, and fullscreen doesn't have decorations.

All of these are off-topic when comparing between mpv's and MPC-HC's fullscreen UI. The actual video area covers the whole screen, with a bottom bar on top of video on hover, just like mpv currently does.

Additionally default 0.5s of hide timeout in mpv is very quick to hide any controls, so they are not obstructing any view more than they have to.

They are obstructive than the current behavior. Currently, I can move the mouse to the top half of video and the bottom bar will immediately hide. Now I have to wait until the timeout of the top bar runs out. And I cannot park my mouse on the top half of screen so a small mouse movement (caused by a bump of table etc) will not cause the top bar to show up.

Also note that there is currently a bug, where window controls are based on title-bar and border options, while also in fullscreen, and since many users actually disable window decorations, because they are unnecessary for mpv in practice, the window controls actually are enabled by extension also in fullscreen mode and no one really complains about it.

A new option that separately sets the window control behavior for fullscreen can fix this, which is what this PR should have done.

[kasper93]

Fullscreen controls that are there to show functional elements of the applications. Not window decorations, because they achieve window management functions rather than as an interface for application functionality.

That's simply not true.

In YouTube, the top bar shows video title because it is not shown in the bottom controls, and the fullscreen toggle is at bottom right. There is also no functional controls on the top bar.

In all other streaming services there are.

In mpv, the top bar does not provide addition useful information like YouTube player does because the title is already shown in the bottom bar

That's fair, we can remove title from top bar, and make it similar to VLC and MPC-BE, and most streaming services, where indeed this information is not duplicated.

The newest version of VLC does not have top bar at fullscreen by default, at least on Windows where I tested.

VLC 4 does have it, older interfaces indeed were more limited in this area.

All of these are off-topic when comparing between mpv's and MPC-HC's fullscreen UI. The actual video area covers the whole screen, with a bottom bar on top of video on hover, just like mpv currently does.

This is very relevant, because this is context of player design. All newer version has top bars, which did major redesign to old MPC-HC.

The actual video area covers the whole screen, with a bottom bar on top of video on hover, just like mpv currently does.

And just like mpv with top bar. Nothing changes.

They are obstructive than the current behavior. Currently, I can move the mouse to the top half of video and the bottom bar will immediately hide.

That's fair point, I will adjust dead zones to account for that.

And I cannot park my mouse on the top half of screen so a small mouse movement (caused by a bump of table etc) will not cause the top bar to show up.

So, when user wants to have top bar, they cannot bump the table? You know this is bogus argument. There is minmousemove and deadzonesize, both of which are better to resolve the issue you describe.

A new option that separately sets the window control behavior for fullscreen can fix this, which is what this PR should have done.

Sure, I can add an option.

[na-na-hi]

That's simply not true.

OBS studio: fullscreen has menu bar, no window controls.
Blender: fullscreen has menu bar, no window controls.
Almost all games (which are the vast majority of full screen applications): many in game UI elements, no window controls.
Emulators: many in game UI elements, no window controls.

There are many applications that do not put window controls on the top bar.

In all other streaming services there are.

They are not window controls, because the embedded videos are not top level windows. In the current mpv implementation the window controls is explicitly designed as a replacement for system-drawn window controls.

All newer version has top bars, which did major redesign to old MPC-HC.

I downloaded https://github.com/clsid2/mpc-hc/releases/tag/2.6.3 and there is no top bar.

[guidocella]

Both uosc and modernz do this at least.

[kasper93]

@na-na-hi: Added an option as requested, is it ok now?

[guidocella]

I don't see how an option is better since you can already change this in a conditional profile.

[kasper93]

I don't see how an option is better since you can already change this in a conditional profile.

It gives consistent default behavior. You could say that windowcontrols=auto could also be done in conditional profile and yet it's auto.

[guidocella]

The advantage of auto option values is that they are used by default. If windowcontrols=auto was not the defaut it would indeed be unnecessary.

[kasper93]

The advantage of auto option values is that they are used by default. If windowcontrols=auto was not the defaut it would indeed be unnecessary.

This is exactly why we need option for fullscreen, so =auto works correctly by default.

[na-na-hi]

Added an option as requested, is it ok now?

Yes, looks ok now.