|
Rockbox mail archiveSubject: Re: what to do about bookmarks?Re: what to do about bookmarks?
From: Magnus Holmgren <lear_at_algonet.se>
Date: Mon, 11 Aug 2008 19:16:05 +0200 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 Received on 2008-08-11 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |