From: alex wallis <alexwallis646_at_googlemail.com>
Date: Mon, 11 Aug 2008 17:24:30 +0100

Hi. While I don't fully understand all the technicle changes you are
suggesting, I think that naming of the bookmark should be optional, i think
that for those who want it the current method of naming bookmarks should
still be available, as speaking for myself i really can't be bothered
messing around naming something that i will probably delete shortly after
creating.

secondly, I like the idea of having a single screen for bookmarks, I think
it is very confusing rb being able to maintain 2 lists of bookmarks. I think
that we should still have access to the bookmarks list from the main menu,
as we currently do with the recent bookmarks list. But it would be good if
we only had one central list to deal with relating to all folders and files.
----- Original Message -----
From: "Jonathan Gordon" <jdgordy_at_gmail.com>
To: "Rockbox development" <rockbox-dev_at_cool.haxx.se>
Sent: Monday, August 11, 2008 4:36 PM
Subject: what to do about bookmarks?


> 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