This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#6272 - Autocreate bookmark if bookmark file exists
Attached to Project:
Rockbox
Opened by Stephane Doyon (sdoyon) - Wednesday, 01 November 2006, 06:28 GMT+2
Last edited by Torne Wuff (torne) - Monday, 05 July 2010, 18:43 GMT+2
Opened by Stephane Doyon (sdoyon) - Wednesday, 01 November 2006, 06:28 GMT+2
Last edited by Torne Wuff (torne) - Monday, 05 July 2010, 18:43 GMT+2
|
DetailsThis patch adds a new option to the "Bookmark on Stop" setting, which
will automatically add a new bookmark on stop, but only if a bookmark file already exists. I want bookmarks for my audiobooks, but not generally when browsing my music. I find it annoying to have all these .bmark files popping up all over the place. With this option, I can indicate exactly which directory / playlist should be bookmarked: if I want bookmarking, I create the first bookmark explicitly. Once that's done, future bookmarks are added automatically. And if I did not create a bookmark by hand, none is automatically saved. How does that sound? On a related subject: the dependency between "Bookmark on Stop" and "Maintain a List of Recent Bookmarks?" is rather confusing. Wouldn't it be clearer if: -"Bookmark on Stop" did not have any options relating to "most recent bookmarks", -"Maintain a List of Recent Bookmarks?" had no / yes / ask, -and possibly we could add an additional option to determine whether the "most recent bookmarks" should be "unique only" or not... |
This task depends upon
Closed by Torne Wuff (torne)
Monday, 05 July 2010, 18:43 GMT+2
Reason for closing: Fixed
Additional comments about closing: A simpler version of this has been committed in r27294 - it just adds an auto-update-bookmarks option, which will cause existing bookmark files to always be updated without prompting. If the file doesn't exist, the behaviour will be determined by bookmark on stop. This should cover all the combinations of desired behaviour here, and is simpler to read :)
Monday, 05 July 2010, 18:43 GMT+2
Reason for closing: Fixed
Additional comments about closing: A simpler version of this has been committed in r27294 - it just adds an auto-update-bookmarks option, which will cause existing bookmark files to always be updated without prompting. If the file doesn't exist, the behaviour will be determined by bookmark on stop. This should cover all the combinations of desired behaviour here, and is simpler to read :)
would disallow manual/explicit bookmark creation...
some were still there. Here's another patch, against CVS of a few minutes
ago and with nothing else applied (really this time). Sorry for the
fuss, and thanks for the feedback.
> If "Maintain a list of recent bookmarks" is enabled with the current patch,
> a recent bookmark gets added when one presses stop even if "Bookmark on
> stop" is set to "If bookmark file already exists" and a bookmark file does
> not exist.
Yes, I realize I forgot to discuss that, but that's the way I would like
it to be. That way I can still go back to some of the last music I
browsed recently. I use .bmark files for books and podcasts, and the "most
recent bookmarks" seems most useful to me when it does record all the last
things you've listened to.
I suppose some people might like it differently. As I said at the top of
this ticket, seems to me the autobookmark preference could be structured
better.
The problem with separating recent bookmarks from bookmark on stop is that if you want to only add a recent bookmark when you press stop, you can't. Your version of the patch does allow for this, but as I note above, this is ocunter-intuitive for some. Unfortunately, I don't presently have any better ideas...
It would seem useful to have one file that it written on power off that contains a list of STOP/tracks. Only recent STOPs would be logged. Old STOPs would fall off the list. That would take care of "missing" STOP/tracks.
However, in any case, I prefer the auto bookmark feature to the bookmark on every STOP.
I prefer it this way because I can put such a file in my /Podcasts directory and all my podcasts (which are stored in a subdirectory per feed) will be subject to bookmarking without having to create a new bookmark file every time I add a podcast. Also, I can delete old bookmark files at will to reduce clutter. All the while, my files in /Music will not create bookmarks because I don't have a "can_bookmark" file there.
I see both Stephane's and James' points about the Recent Bookmark menu. Ultimately, I think the bookmark options would be well-structured if they went something like this:
When to bookmark
- On stop
- - Yes
- - No
- On shutdown
- - Yes
- - No
Bookmark creation behavior
- Create bookmark file
- - Always
- - If directory/playlist is flagged as bookmarkable (something like what I explained above)
- - Always ask
- - Ask if directory is bookmarkable
- - Never
- Add to recent bookmarks menu
- - Always
- - If directory is bookmarkable
- - Always ask
- - Ask if directory is bookmarkable
- - Never
Bookmark file loading behavior
- Automatically
- Ask
- Only when manually selected
Recent bookmarks menu behavior
- Maximum length
- Permit multiple per playlist/directory?
- - Yes
- - No
bookmark options could use some restructuring... But in the meantime,
here's the updated patch which I use.
This one should be much more useful :-).
and books but not my music... and this does exactly what I want.
I guess the other things discussed above might be more flexible, but I think your patch is nice because it is very simple but still makes life much easier.
One minor functional change: make write_bookmark return false if the bookmark is not going to be written because no file exists. This more accurately reflects the other cases where false is returned if autobookmarking is disabled. Nothing actually checks this return code at present, but it seems like the right thing to do.
I really wonder why this one isn't on svn -- it's not closed, so there are probably no immediate objections. As to its usefulness, it's imho a must-have for those with audiobooks, podcasts etc. Does not bloat the code or ui either. It is natural to bookmark large books and not to bookmark 12p leaflets. Plus, it's an option.
This is on my list of things to revisit (I am a committer) but I have not yet spent the time on revising the settings UI to a point where I consider it acceptable. A better way to solve this problem might come along before then :)
I also was checking how easy / elegantly it would be to implement a conditional auto bookmarking based on the genre tag, with a user tags list («Audiobook», «Speech», «Podcast» etc). Or a custom one («Bookmarkable»), or smth. Or maybe both -- if a custom tag is not against the RB mojo. And I cannot see a nicer way than the Sdoyon's -- same thing, just with tags.
Marking directories seems smarter -- radically smarter if that would allow recursion, so you would need to mark only the root folders (2-4 ../ checks won't slow it down much). Just check for the '.bookmarkable' file recursively up, this seems simple... hm.
Torne, what would be your advice? Write the tag patch, write the rec dir marking patch, wait for you, or wait for bookmarking to be redone by unknown forces, using the Sdoyon's patch until then? First two options won't deliver much of a beauty, as I'm a less brighter coder than my cat supposes.
If you want something done in the short term that will be reasonably usable, then propose a nice way to structure the bookmark settings so that "if already exists" fits in neatly with everything else - I am not sure what one would be :) If it seems nice then someone (you, me, someone else) might implement it and then that can probably be committed as a short term measure until a much nicer way to handle this globally comes up.
New setting "Auto update", yes or no - If yes, it updates any bookmarks that already exist, and if no it doesn't, regardless of how they were created. This means that whether bookmarks are created automatically, are asked for on stop, or are only created manually they will be updated next time you stop playback, if they already exist.