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

[The Wanderer]

Reimar Doeffinger wrote:

> Hello, On Fri, Sep 07, 2007 at 05:53:56PM -0400, The Wanderer wrote:
> 
>> Reimar Döffinger wrote:
>> 
>>> Then maybe you try more to explain your likes so either they can
>>> be satisfied without a new commandline option or I can at least
>>> start to see the need for it.
>> 
>> In the previous case, I think I've already argued it as far as I
>> can, and you don't seem to have been swayed in the slightest; my
>> objection there was not so much on like/dislike as on the fact that
>> something which had worked before (and seems like it should be
>> common) had stopped working, and the thing which had been fixed by
>> the change seemed like it should be much more rare than the thing
>> which broke. And, of course, I used the behaviour which broke but
>> am unlikely to ever use the thing which was fixed.
> 
> Then why not give me the specific use case? An example of a scenario
> that would make MPlayer work worse for you.

...I thought I *had* given the use case at the time, at least if I'm
understanding the term correctly.

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. Before the change, if I told the window
manager "remember the location of this window", then the window would be
in the same location next time even for a different file. After the
change, the window always appears in the middle of the screen
regardless. It is, of course, possible to override this with -geometry,
if one knows the correct coordinates (although figuring those out is
considerably less convenient than just having the WM handle it) - but
the fact remains that failing to be compatible with window-manager
location memory constitutes loss of functionality.

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.

The specific context in which I was using window-manager position memory
is in placing the MPlayer window in a specific location with respect to
my Japanese-English dictionary program, for convenience when I am
translating text from e.g. anime title screens. It has become much more
difficult to do that conveniently since the change took effect,
particularly since I frequently need to seek back to the exact same
location repeatedly and there is no convenient way to do that without
quitting and restarting - which, now, results in having to move the
window again (and so is much less convenient).

>> In this case, my only real argument aside from "it's a change,
>> change is bad" (which I do not really agree with) is that the
>> current behaviour *does* make sense in context of the other MPlayer
>> options, and while the behaviour I think I understand you as
>> changing this to may also be desirable, it does not to me seem
>> desirable enough to break the existing paradigm.
> 
> I don't consider it breaking any paradigm, but actually "fixing" an
> existing one: That interactive changes should override commandline
> options.

Yes, they should. The question is to what extent. I am saying that the
answer may be different in different contexts, and so both behaviours
should be available.

> The change is that such an override should also persist beyond file
> change, so it could be argued that this is more that just extending
> current behaviour.

I don't know if I agree with that "should".

Are there any other command-line options which also correspond to
interactive commands?

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?

I can see a few cases where it might be useful for them to, but I can
also see other cases where it would definitely not be desirable. Again,
at best I could support providing both behaviours.

>>> Huh? They only mail that said something like this was in reply to
>>> a suggestion for a _completely different_ approach at this,
>> 
>> As long as the effect is the same (in terms of removing the
>> existing behaviour), which as far as I can tell from scanning the
>> patch it appears to be, the same rationale applies.
> 
> Well, the difference is that my patches only changes current
> behaviour when the user explicitly switch to fullscreen.

...then perhaps I've missed something. I thought that *all* of the
possible patches under discussion (whether created yet or not) were
changing that and only that.

I am saying that I do *not* want to have toggling the current file to or
from fullscreen automatically set all subsequent files to the same. Just
because I have explicitly made the change for this particular file does
not necessarily mean that I want to make the change for all others.
There are times when it does, but there are also times when it might
not.

>>> and the other mail from you in this thread I replied to but never
>>> got an answer to...
>> 
>> I have made two previous posts in this thread; you replied to one
>> of them, which was itself a reply to your post which started the
>> thread, but not to the other. Your reply did not, so far as I could
>> tell, contain anything which invited a response; you specifically
>> said "I don't believe the old behaviour to be desirable enough to
>> keep", which A: does not exactly inspire confidence in your
>> willingness to be convinced on the issue, and B: is hard to argue
>> against, as it's primarily a matter of opinion. My only argument
>> against it (at least so far) is the very matter of option
>> consistency which I mentioned above.
> 
> Obviously there was quite some misunderstanding. Firstly I used
> "believe" as in "I don't believe the old behaviour is useful to
> anyone" - which (in that sentence obviously) does not mean I can't be
> convinced but just that I do not know.

It sounded to me like an expression of fixed opinion - specifically, the
opinion that the old behaviour was in no way desirable.

This is probably another manifestation of the difficulty of nuanced
communication in a purely text medium; however, the phrasing used simply
sounds dismissive to me.

For what it's worth, I would (and did) read "I don't believe X" as being
a much stronger negative statement than "I don't know X". Belief is much
harder to overcome than simple lack of knowledge.

> Also your argument about consistency did not concern me much, because
> I would tend towards the "interaction overrides commandline
> (permanently)" approach which would be (somewhat) consistent as well.

Yes, it would be consistent in a different way, and it would be good to
have that available - but unless there is some specific reason *to*
remove the existing behaviour rather than keep it, I see no reason to
break the existing (and I hesitate to use the word) paradigm.

> The much better argument is that your objections aren't purely
> theoretical but based on your actual use.

...in all honesty, I'm forced to admit that I'm not absolutely sure that
that's true. Unlike the window-positioning issue, in this case I rarely
do do anything which would be broken by the change you are proposing.

> That is also better, because it allows proposing and discussing
> alternatives to an option, as there are:
> 1) a command to reset such overrides (my suggestion in the email I
> complained you did not answer to)

I don't remember seeing such a suggestion, and I don't see one now that
I go looking for it - but while this would not be ideal, it would still
be acceptable.

> 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).

-- 
       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.