[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 07:12:57AM -0400, The Wanderer wrote:

>> Two examples are hardly enough for a rule, but it feels as if every
>> time you touch the interface-level code, it changes something in a
>> way I don't like...
> 
> 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.

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 see any indication of a way (e.g. by config file option) to
>> produce the previous behaviour, which - as I said in the earlier
>> thread - I think follows intuitively from the option-positioning
>> rules used for the rest of MPlayer.
> 
> 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.

I don't honestly remember discussion of multiple approaches, or at least
not ones which would be different in any significant respect in terms of
the things I care about here.

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

> Adding a command line option is a possibility, but it is a very bad 
> solution and should not be done without good reasons. If there was a 
> sensible way to add it as a suboption I'd be more open to it, it
> keeps the complexity at least a bit more manageable.

...can suboptions be specified in the config file to take effect
whenever their associated option is specified, without simultaneously
having to specify the option itself in the config file and so turn it on
by default? Because if not, having a suboption would not allow me (or
anyone else) to have this default to the current behaviour, and that
ability is my criterion for not objecting to the addition of new
behaviour: that it be an addition, not a replacement.

I agree that this is far too clunky a sort of thing to be well suited
for a separate command-line option, but since which behaviour is desired
is a matter of individual preference *and* we handle user
preference-like settings in the config file *and* the program is
designed such that all config-file entries inherently correspond to
command line options...

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