Writing Playlists
The playlist API had to be designed to make any sort of strange kind of playlist possible, for example, one that accepts the filenames from a socket; this one doesn't fall well into line with all the other kinds of playlists. For this reason, the noatun playlist is a bit funky, and indeed the most difficult type of plugin to develop.
The most difficult job in playlist design is keeping continuity. The splitplaylist, although among the oldest Noatun codebases, hadn't reached total stability for quite a while. This is only necessary if, when you delete an item, it will continue playing it. Due to various SPL design limitations, this no longer functional in Noatun 2.0.
Splitplaylist's method for continuity was to store three pointers: one to the currently playing item, another to the next, and the last to the previous item. That way, even if the current item is removed, we'll still know which to play next. Then, when the next item is played, the three pointers are cycled forward. If an item is moved to where it should be the next item, then the next pointer is modified.
Noatun 1.2 introduces the Property. Any really smart playlist should store all those properties between sessions. Take a look at the API docs for more info on this topic.
Noatun 2.0 introduces Reference Counting to the playlist API. That, of course, is a big change, and writing a Noatun 2.0 playlist is genenerally quite different from a Noatun 1 plugin.
