**TAKING VOTES** osc.lua: make windowcontrols=auto show window controls in fullscreen#17618
**TAKING VOTES** osc.lua: make windowcontrols=auto show window controls in fullscreen#17618guidocella wants to merge 3 commits intompv-player:masterfrom
Conversation
|
@Dudemanguy Thoughts? I saw you mentioned in the previous PR that you personally did not want this. And this PR does not adhere to the behavior you mentioned: #17602 (comment)
If I disable border at runtime I will no longer get any window control with this config. This is much worse than not having window controls in fullscreen.
So is the status quo.
Other popular media players including (non-vaporware version of) VLC and clsid2 MPC-HC do not have them. Also see the CSD bias pointed below.
No one complained about them because windowcontrols makes sense in windowed mode when no border/title bar. By disabling border/title bar the user is showing a preference for CSD, so it is not unexpected that the CSD windowcontrols are shown in fullscreen. And now that they get used to this behavior they complained when they suddenly stopped showing in fullscreen. The default without border/title bar on the other hand indicates a preference for SSD, and showing CSD windowcontrols in fullscreen breaks this expectation. Whether SSD matches the expectation of most users is a question for another day (notably, the showcase screenshots of the popular third-party OSCs mentioned are windowed and use --no-border/title-bar, so clearly they have a CSD bias) , but with the current SSD border/title bar default, I think mpv should also avoid showing CSD by default. For users who dislike CSD, this PR would make them complain too. The status quo satisfies both camp by delegating the decision to the --border/title-bar which indicates CSD/SSD preference.
I for one do not accept the discoverability being used as an argument in a general sense. The same argument can be said that advertisements are good because they make products more discoverable (and especially so for "personalized" ads), so users seeing ads by default with no ad blockers installed is a good thing. Discoverability is only good if it is not intrusive, like the menu button added to the OSC. This is not the case here according to the CSD/SSD argument above and other points I made above and in the previous PRs.
I mentioned before that PR is not a good place for voting, because it is mostly viewed by users who want the change to be made. A poll in discussions is more suitable. |
guidocella
changed the title
|
I don't have strong feelings either way, but whatever let's argue.
Sure I also use the keyboard, but this is also the case for every OSC button.
Fair, fixed by #17619.
Is disabling it at runtime really common? But if you do that you're an advanced user who should be able to write a conditional profile.
Not sure what is the point. The reaction results will determine what we prefer change or the status wuo.
Maybe they just didn't implement them yet since uosc and ModernZ are much newer. macOS adding them automatically everywhere (reported by Akemi/der_richter) strongly suggests to me that they are considered useful so Apple decided to add them instead.
I don't see how SSD vs CSD matters for fullscreen, they are equivalent there because neither takes up extra space, the important thing is having a close button, which is why this commit disables them in fullscreen on macOS which has equivalent SSD. I also seriously doubt that all uosc and ModernZ know how to disable the title bar and yet no one complained about fullscreen window controls as far as I know (@Samillion - can you conform this?). Actually, the only complaint I found is about them being redundant on macOS, which indeed this PR avoids tomasklaen/uosc#913
I don't find it intrusive, you mentioned in the previous PR "I can move the mouse to the top half of video and the bottom bar will immediately hide.", but I did not understand this because the new independent deadzones already fixed this (which along with overlapping OSD text is why we didn't open a PR before).
I don't see why users who don't want the change would see it less, if e.g. the title was "remove the ability to play videos" everyone would see it. I can make it clearer in the title, but I don't think discussions are more viewed their PRs, they are mostly for support questions while development discussion always happend on PRs and #mpv-devel. |
Indeed. Most users are not aware of at least 70% of available options, whether mpv or script specific. I get asked about mpv options on ModernZ, because they don't know the difference. Examples: Samillion/ModernZ#490 and Samillion/ModernZ#395 However, there is a key fact here that is unquestionable: No one ever complained until they were disabled. I am not sure how can that be overlooked. I have never seen You can all debate the design theory of things and differences among software and operating systems, it still does not change the fact that this is the closest telemetry mpv has gotten regarding window controls, and the consensus is they want it back. For those that do not want them, they can still achieve that. It's a matter of default behavior. As for the pressing I personally close with mouse, old habits die hard since Windows 3.1. Regardless, if pressing |
Which means we should be ready to revert it if complaints start coming in. As a reminder, we reverted the previous attempt with this subject after less than 10 complaints on IRC within ~ 3 days. I expect similar vigor with this PR as well, if complaints arrive. I think we should agree on that before this gets merged. Other than that, even if this behavior is not for me, I agree it's worth experimenting with. However...
I agree with that.
Is it really uncommon? we can't know. We don't have telemetry. For me it's very common (really). However, I think we can settle it better. The main issue I think @na-na-hi has, which I'd agree with, is that this PR makes it impossible to get back the current automatic behavior. But this can be solved easily: add an OSC option This obviously won't address annoyance due to the change of default behavior, but as I said, I agree it's worth experimenting with if we keep tracking feedback closely, but it would allow such users to get back their old behavior by flipping an option - which currently this PR doesn't allow. |
Another way to control it is without adding this new option, but adding a new
|
guidocella
force-pushed
the
fullscreen-controls
branch
from
0260f53 to
a8cd7f1
Compare
|
It's definitely possible to get back the current automatic behavior with a conditional profile, but sure I added osc-windowcontrols=auto-windowed (because I think it makes more sense for |
|
Maybe |
The point is to have an option which lets users keep their current behavior. If you want to add more modes beyond that, it's up to you. But the way you phrased it, it sounds like you intended again to remove the option to restore the current behavior. |
I don't mind this, and I don't disagree that "auto" is a good name for the default, but it's a bit weird that a mode called "auto-windowed" only affects the behavior in fullscreen... |
Yes, hence why I asked if it should always disable controls in fullscreen. This seems more intuitive since it was added for the presented use case of disabling the title bar at runtime, but I don't see why this should change your preference for window controls in fullscreen. |
|
Just pick something which allows to keep the current behavior, and document it well. Beyond that, up to you. |
I agree with what @avih said here. And it is not up to anyone to determine whether someone is an "advanced" user or not. "Advancedness" exists in a spectrum. A user can have the ability to write something like
Do you have evidence to back this up? And as I mentioned before, there is not adopted by lots of programs in practice, even new ones. VS Code is an example of a modern, popular editor that hides window controls in fullscreen.
It is SSD added by macOS according to its HIG, and also includes global menu which is not part of the window. This is not CSD window controls.
windowcontrols cover up part of video so it is not correct to say that it takes no extra space.
uosc and ModernZ users are not general mpv users. They clearly have difference UI preferences, and the reason that they are using uosc and ModernZ in the first place might be because they want fullscreen window controls. So it does not tell us anything if they are not complaining. The question here is about the default osc.lua and its user base.
Similar feature used in chromium-based browsers ('X' button that shows up when mouse hovering near top of screen) is considered intrusive by many users: brave/brave-browser#42394. And this is just one exit fullscreen button which occupies less space than a full window control title and close/maximize/minimize buttons, not to mention that the mpv window controls are easier to activate due to lower deadzone.
Discussions and issues are visited mostly by users, while PRs as you said is mostly for development, so visited mostly by developers. This makes the user base and opinions posted in PRs inherently biased, and why PR is not a good place for polling opinion of general users. No one complained in the PR that made the windowcontrols never shown in fullscreen by default. They only complained after it is merged. Users generally do not care about PRs until something breaks.
Yes. Everyone will complain when their current expectation is broken. Same for the users who are satisified to the status quo. This tells nothing about whether we should start enabling it for users who chose not to change the default, which also breaks their current expectation. In fact, this means that enabling this by default should be a careful decision, because if you remove or redesign it later to something different, everyone will complain. |
|
We can just A/B test this. We had for one week a test where window controls were disabled, now we can have one week when they are enabled, and monitor user feedback. I personally, don't see this as a big deal, the controls are not that obstructive, especially with split zones. I don't want to argue about this, because we all are missing information that would definitively make this decision. But I feel like it's made to be bigger deal that it really is, to be quite honest. Also there is clear distinction with "removing a feature" or "adding a features". Clearly what we did last week was ill-fated as we removed a feature that confused the users, regardless how this feature was enabled. OTOH enabling window controls, from the user point of view is "a new feature", imagine those controls never existed, and now they are added. |
|
Stop wasting your time arguing with bad faith actors, there's a vote and people have voted. |
I think it is better if the deadzone is adjusted so that the window controls only show when the mouse is at the top border, because this is what is needed to trigger showing for most of the other programs I tested that do have window controls in fullscreen, like Firefox and some remote desktop programs. This keeps intrusiveness at minimum. If this is done then I am OK with the A/B testing.
Alleging bad faith when I am arguing technical aspects of the PR is a bad faith in itself. This is not the first time you accused me of bad faith and this is not constructive. Stay away if you have no valid criticisms to say. |
This allows quickly quitting mpv in fullscreen. --script-opt=osc-windowcontrols=auto-windowed restores the previous behavior. Arguments for this are: - Both of the most popular third-party OSCs (uosc and ModernZ) enable them. - macOS adds them to all fullscreen windows automatically. This commit therefore avoids enabling then on macOS, because they would be redundant. - Since 353e4ef (6 years ago) they've been enabled in fullscreen with no border/title-bar without anybody every complaining about them. When we removed them, even though it only affected this non-default configuration, several users came to IRC to complain in a short time. - It's easier to disable features than to discover that they exist.
This changes the window controls dead zone size to 1, instead of being the same as the main OSC, so they are less intrusive.
guidocella
force-pushed
the
fullscreen-controls
branch
from
a8cd7f1 to
d2565e1
Compare
|
Trivially added OSC script-opt names mixing attached words and _ separators are pretty unfortunate. |
|
Actually is there a reason we don't just keep only the top right buttons like in floating layout? They are certainly less intrusive there. |
|
Removed the bar and title, I think it is way better.
|
I think it looks better now without the title bar in fullscreen, but wouldn't |
|
The title is already at the bottom no? |
Keep only the buttons to make it less intrusive. osc-windowcontrols_bar configures this behavior.
guidocella
force-pushed
the
fullscreen-controls
branch
from
1ea5623 to
a7a0824
Compare
|
I don't understand what you removed but I made it configurable.
|
|
This is purely a personal taste thing, but I do not want any window controls if the mpv window has borders. Maybe this is a desktop linux-ism, but CSD and SSD were always separate states to me and I never liked mixing them both: even in the fullscreen state (which of course just means no decorations at all). I personally don't see the value in having all these options or changing the old behavior. Did anybody complain about it before in the past? So I guess I'm a "no" vote here, but I'm not going to die on a hill for this. |
This is another default behavior change, and I pointed out before that the bar should be kept if the user has disabled border/title bar. This has already caused someone to complain that the bar is no longer showing. |
|
There are too many thumbs down which would correspond to too many user complaints. Users who want this can enable it in their config: I can resurrect commits 2 and 3 if someone wants them. |
7 participants
This allows quickly quitting mpv in fullscreen.
Users with --title-bar/border who don't want them can disable them with --script-opt=osc-windowcontrols=no with no need for conditional profiles. For users who disabled --title-bar/border, nothing changes.--script-opt=osc-windowcontrols=auto-windowedrestores the previousbehavior.
Arguments for this are:
Feel free to react with thumbs up or down depending on whether you agree with the change.