Jonathan Gordon wrote:
So this is my suggestion for what to do about bookmarks. I dont use
bookmarks so if someone who does could comment that wouild be
great...
instead of a separate file format for .bmarks, the .playlist_control
file for the current playlist would be copied *somewhere* and the
needed resume info would be appended to it as a comment (which
playlist reloading would ignore).
But .playlist_control isn't a playlist, but rather use a Rockbox-private
format (like the current bookmark file), so we can easily add a new
playlist control "command" to indicate a resume position.
And if another playlist control is used (after being copied), the
central .playlist_control would just contain a reference to it.
Once the bookmark is saved some flag in the playlist control struct
would be set so we know if its modified later. (BRAINDUMP, add the
bmark fd to the playlist sturct and put all the creation
responsibilities in playlist.c so bookmark.c just handles the UI) If
the user creates a bookmark again and the control file wasn't changed
the 2nd resume spot will be appended to the existing .bmark file (or
maybe ask the user what to do?) If the control was changed we have to
create a new bmark file (which is fair enough imo).
I'd really like the ability to keep more than bookmark for a playlist.
It might not need to be unlimited as it is now, but more than one is nice.
One thing about adding bookmark reading/writing handling to playlist.c:
it is already quite large and complicated. A bit of cleanup/refactoring
would probably be nice before doing that, e.g., split out the code
directly dealing with the the .playlist_control file...
Now, here is the tricky bit... Where do we store the .bmark? If its a
dirplay or m3u8 playlist then we can save it as <foldername>.bmark or
<playlistname>.bmark in the same folder as the dir or m3u (current
behaviour)
database playlists? inram playlists? (from the playlist POV there is
no difference between these, but there should be... thats something
for later though).
In-ram playlist is only used for dirplay, as far as I know. If so, then
that won't be a problem.
One problem with the playlist control file for a database selection is
that it can be quite large (one line for each found entry). This can
make things a bit slow (reading/writing individual bookmarks, mainly).
I'm thinking we could store it in /bookmarks/ and show the keyboard
so the user can choose a name? as long as the resume point is stored
straight away then any delay naming the file wont cause an issue with
the wrong point being saved.
How handle name collisions? Because to keep current behavior, you need a
good, unique mapping from a playlist file/directory to the bookmark
file. Database results could (should?) be stored centrally though.
Then that begs the question, why not save all bookmarks in the one
folder and then we can replace the "recent bookmarks" screen with a
file browser pointing to the right folder?
Wouldn't be quite the same, unless you make the recent bookmark screen
open each file and read the latest bookmark, which could be a bit slow...
Magnus
