[MPlayer-dev-eng] [RFC] keep fullscreen mode over aspect, file etc. change if set by user

[The Wanderer]

Reimar Döffinger wrote:

> Hello, On Fri, Sep 07, 2007 at 08:16:17PM -0400, The Wanderer wrote:
> 
>> The previous case was the one corresponding to r18718. Before that
>> change, MPlayer was compatible with window-manager window position
>> memory; afterwards, it was not.
> 
> [...]
> 
>> The change which was fixed by that commit was that, if you
>> specified -fs, -fixed-vo and multiple files, then changed back from
>> fullscreen on something other than the first file, the window would
>> still have the resolution of the first file.
>> 
>> I did not and do not see how situations in which the pre-r18718
>> behaviour is a problem is likely to crop up anywhere near as often
>> as situations in which the post-r18718 behaviour is a problem.
> 
> In addition the old code also cause the window to wander further down
> with each aspect change and I think also with each time I switched
> from fullscreen to windowed mode.

I don't remember this being mentioned at the time, but since last time I
searched I couldn't find the original (pre-commit) discussion I'll take
your word for it.

> But the bigger problem I as the one wrangling with the code is that 
> while you preferred this behaviour it was not at all what the code
> was _supposed_ to do, and what it actually did was mostly a function
> of the window manager leading to hard to reproduce behaviour and
> complaints.

I do not see how it is desirable to be explicitly incompatible with a
fairly standard window-manager feature. Most of the time, the user will
not have requested the window manager to remember the window location,
and in that case I think the current behaviour is good - but if the user
*has*, we should *not* ignore that.

Window position is, in many respects, properly the domain of the window
manager anyway...

> There was an attempt to fix this properly again, but nobody is 
> interested enough to keep the issue alive (and if necessary beat me
> to accept a solution I don't like), the only thing coming out of it
> was yet another ugly bloaty hack added to a window manager...

I don't know if I remember the attempt, and I'm not sure I understand
what constitutes "proper" in your view in this context, but at this
point - as long as nothing else gets broken in the process - anything
which restores compatibility with WM position memory should be fine by
me.

>> Volume, OSD level and audio delay are the only ones I can think of
>> offhand (aside from seeking, which is not persistent), and all of
>> those reset to their command-line-specified values at file change.
>> Would you argue that those should also persist between files?
> 
> Volume does not reset (at least not if it's a hardware mixer, not
> sure about -softvol), but there is no way to set volume from
> commandline anyway.

-softvol is what I"m talking about (since I don't have a hardware
mixer), and indeed it does reset - or at least it did last I checked.
And yes, you can in some sense set volume from the command line, using
-af volume.

>>> 2) a different command, one which overrides options and one which
>>> does not. I am not sure how to implement this, properties do not
>>> seem to like an additional option, and a command/property with a
>>> completely new name seems a bit ugly to me.
>> 
>> Seems kind of ugly to me as well, but for that matter, so does my
>> own suggestion of an option to choose which behaviour is desired -
>> which, for the record, I would still prefer to anything else
>> suggested so far (even over simply not changing the behaviour at
>> all).
> 
> I forgot
> 3) make it depend on -fixed-vo: old behaviour with -nofixed-vo, while
> -fixed-vo keeps fullscreen state.

This would sort-of fix things for me for the short term, since I don't
presently use -fixed-vo, but since that will not necessarily remain the
case I'm not sure it's good in the long term. I also have the
understanding that there is the possibility of dropping -nofixed-vo
entirely at some point...

> 4) add INITED_USER_FLAGS or similar to uninit_player that resets
> these, thus keeping the current behaviour and only "fixing" aspect
> changes (or other mid-stream resolution etc. changes).

I'm not sure that I understand this, but if I do, then it sounds almost
ideal for my purposes. Then again, I'm not sure how this would address
the issue at hand, which is that some people want fullscreen status
(once toggled) to persist between files and others do not.

I had another idea last night for a possible approach, but I seem to
have forgotten it in my sleep.


Yet a separate idea would be to do something comparable to e.g. the
"pausing_keep" slave-mode command prefix - make it possible to specify
e.g. a "persistent" prefix (or not prefix, but you get the idea) in the
keybindings file. Then you give the new behaviour if that flag has been
specified for the "toggle fullscreen" key, and the old one if not.

This has the advantage that it could be extended to do the same kind of
thing for all other potentially relevant commands, not just fullscreen.
It has the disadvantage that it might be horrendous to code cleanly.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.