[MPlayer-dev-eng] [PATCH] GUI: Enhancement to r35555

[Ingo Brückl]

Hans-Dieter Kosch wrote on Tue, 11 Dec 2012 02:35:23 +0100:

> Ingo Brückl wrote:
>> Hans-Dieter Kosch wrote on Mon, 10 Dec 2012 18:36:40 +0100:
>>
>>> Ingo Brückl wrote:
>>>> Hans-Dieter Kosch wrote on Sun, 09 Dec 2012 21:48:24 +0100:
>>>>
>>>>> Ingo Brückl wrote:
>>>>>> Hans-Dieter Kosch wrote on Sat, 08 Dec 2012 23:31:27 +0100:
>>>>>>
>>>>>>> If the current file is still present in the list, playback continues with
>>>>>>> adjusted position.
>>>>>> I've considered this in r35555, but we don't know anything about the files
>>>>>> before the present one. These might have changed, too, so it's best to
>>>>>> restart playback, because I don't think it's worth to check the list of file
>>>>>> before it. (The reason for r35555 was to allow adding to the playlist while
>>>>>> playing, not to change it at this stage.)
>>>>>>
>>>>> This was also my concern at first. However, since the playlist is
>>>>> completely recreated upon selecting 'OK', we are always in sync, and it
>>>>> works flawlessly. You can edit anything in the list, no issue will arise.
>>>>> Or did I miss something?
>>>> No, there is no problem with the list or on-the-fly editing.
>>>>
>>>> It's just that we don't know what the user meant with the editing if the
>>>> position has changed (inserting an item, or delete one and/or exchanging some
>>>> before the current one). To avoid extensive analysis that probably won't help
>>>> us anyway, we simply restart. It's not worth the effort.
>>>>
>>> But I don't see any problem. I think it's just intuitive and logical;
>>
>> I don't think so. Let's say the list is "a b c d e" and "c" is currently
>> playing. If there is a change to "a b x c d e" or "y c d e" why would it be
>> intuitive and logical to ignore new "x" or "y"?

> They are not ignored, I've verified again, with my patch applied [...] and
> stepping back plays 'x'

Yes, of course.

By "ignore" I didn't mean ignored by manual actions. My point was: If a user
adds "x" would he expect that playback continues as if he hadn't done
anything?

On the other hand, he somehow tried to change the past...

> The current code correctly recreates the running playlist on the fly.

I know. That was never a problem with the playlist. (It would even expand
playlist files as part of a playlist during playback if MPlayer itself would
still get mpctx->file_format DEMUXER_TYPE_PLAYLIST.)

>> Unlike a TV receiver program list a playlist is meant to be played from
>> the beginning to the end.

> OK, this depends on how you define a playlist. I see a playlist as a
> collection of files to be played up and down and to be edited to taste,

You expect new files after the current one be played while new files before
it will be "ignored".

Well..., I could warm with a point of view that a playlist is meant to be
played from the beginning to the end, but that editing before the current
item in a running one can't have immediate effect, but only after playback
has ended (and the track automatically resets to #1). In stop mode however,
any editing should reset to track #1 then.

That would meet my expectations. What about yours?

> Why should we [...] force a specific usage? We could give the user more
> freedom without side effects.

It depends on personal point of views what "force" or "freedom" or "side
effects" might mean. What seems to be "a right program behaviour" for one
person, may be "wrong" for the other.

BTW, I've by now fixed everything on my list concerning playlist (except
editing), PREV, NEXT (both playing and in stop mode) with displaying,
preserving or clearing media data for files, CDs, VCDs and DVDs. I hope that
there are no more issues.

Ingo