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
> 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
> 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...
Received on 2008-08-11