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

[Hans-Dieter Kosch]

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. In your first 
example, 'c' is renumbered from track 3 to track 4, and stepping back plays 'x' 
at track 3, 'b' at track 2, ... In your second example, 'c' is renumbered to 
track 2 and stepping back plays 'y' at track 1. In all cases, stepping forward 
correctly hits 'd' and 'e'. The current code correctly recreates the running 
playlist on the fly.

> Unlike a TV receiver program list a playlist is meant to be played from the
> beginning to the end. So the only intuitive and logical behaviour is to allow
> changing items no yet played and to either forbid everything else or to treat
> the result as a new playlist (and thus restart).

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, and if items around 
the currently playing one are changed, the current one is not affected besides 
its track number, and you can navigate freely in the changed playlist. The 
actual code achieves this perfectly.

Why should we forbid something, that's really working and force a specific 
usage? We could give the user more freedom without side effects.

> (And yes, I know that the
> current code doesn't recognize exchanges like "u v c x y" - you have to
> change in stop mode for a restart then.)
> 
Even this works perfectly now on the fly, thanks to your previous changes. I 
couldn't find any bug.

N.B.: Above explanations presume of course, that the playlist is edited via the 
GUI, not from outside.

Hans-Dieter