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

[Hans-Dieter Kosch]

Ingo Brückl wrote:
> 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".
Of course, they are "ignored" for the moment, as they are located before the 
current playing. But stepping back will meet them.
> 
> 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,
Just like editing after the current item doesn't have immediate effect, too. I 
didn't expect e.g. to jump to a newly added item. Simply continue playing the 
current one undisturbed.
> but only after playback
> has ended (and the track automatically resets to #1).
Yes, clearly. Or when navigating back, where the edited items are correctly hit.
> In stop mode however,
> any editing should reset to track #1 then.
> 
> That would meet my expectations. What about yours?
The same. I've seen, you've committed it. It's perfect now!

I believe to see now where our misunderstandings were rooted: Seems you looked 
at the playlist as a quite static sequence of predefined files and esp. the past 
before the current item more or less frozen, whereas I see it as a dynamic list 
which can freely be edited and navigating forth and back meets the actual 
contents. And that works!
> 
>> 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.
You're so right...
> 
> 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.
> 
Yes, probably, hopefully, but it's all very complex (how often I thought in my 
professional work, now all is fixed, but then...). Let's play and see :-)

Once more: MPlayer is great work!

Hans-Dieter