From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Tue, 12 Aug 2008 01:36:09 +1000

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). 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).

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).
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.
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?


Thoughts, comments?

Jonathan
Received on 2008-08-11