Opinions of User-friendliness in rockbox

[ryran]

Been following all this with interest... chuckling a bit, though.

Gotta say, I'm with Paul on this one.

[cpchan]

If it's hidden by the OF, it won't show up by default on their computer either... How exactly is having Rockbox not hide files marked as hidden (and probably hidden on the original computer) least surprise?

I believe most tech unsavvy users tends to just sync their players with their music manager, at this point,  in mtp mode with the OF. For those savvy enough to use ums, they should know about the hidden directories. I guess I am just sick of those "I can't find my music folder" posts.

Charles

[Llorean]

If you sync a Sansa with MTP mode (at least the C200 on Vista, for me) the files are renamed anyway. Making the folder unhidden won't help much.

[cpchan]

If you sync a Sansa with MTP mode (at least the C200 on Vista, for me) the files are renamed anyway. Making the folder unhidden won't help much.

Hum, interesting- I didn't know that. I have no experience with either Vista or the c200 series. This is getting as bad as iTunes.

Also, I didn't know about the dot file limitations in Windows Explorer.

Charles

[Llorean]

This may be a feature of the original firmware. But I firmly believe the answer to the OF hiding and/or obfuscating files is a "Known Issues" section in the beginning of the manual.

We're always going to have to tell people what iTunes does to songs. Or that the OF might do things to their files. Or other things. Make it clear to the user, instead of simply trying to pretend like it doesn't happen. Otherwise you'll just get "I can see my Music folder on my e200, but I can't get to it on my computer! What do I do?" instead of the other way around.

If we really want to do "least surprise", Rockbox would have to scan OF-specific folders and fix filenames too. Instead we have the database, which will work just fine for hidden files too.

[saratoga]

Regarding the hidden folders by the OF on the Sansa, its probably reasonable to simply revert the hidden flag on start up since it could be put in Sandisk specific files where it would not clutter the main rockbox source or burden non-Sandisk.  At least if someone submitted a sufficiently well made patch I would consider committing it.

I do agree that any sort of system wide hacks to address this issue are very bad idea though.

[Llorean]

If there's an option to unhide that folder automatically, it needs to be optional I think. Just an option "Unhide music on boot", probably defaulting to enabled, and only existing for players that have hidden folders that they put music in by default. Or maybe even simply "Always show MUSIC folder" with "MUSIC" being dependent on what the OF might name it (for future firmwares).

[cpchan]

Or maybe even simply "Always show MUSIC folder" with "MUSIC" being dependent on what the OF might name it (for future firmwares).

I second this solution.

Charles

[JdGordon]

Or maybe even simply "Always show MUSIC folder" with "MUSIC" being dependent on what the OF might name it (for future firmwares).

thirded

[bascule]

bookmarks: Yeah, they're at least half broken most of the time, aren't they? Maybe a GSoC project could be removing then, and reimplementing them from scratch with a better UI?

...and working from the Database, please...

Oh no; it's the only functionality my Rio Karma had that I still miss.

It showed previous track to current +7 or 8 with the current track in bold with full playback/sound controls active.

suggestions on how it could work with the various targets?

Would a list widget in a viewport work? I *believe* the playlist view is not a simple list widget, but that is how I see it being implemented. You couls then have a full screen viewport containing the 'playlist widget'.

[pondlife]

I think I pretty much agree with Llorean, so I'll quote him...

quickscreen: Repeat and shuffle often have dedicated buttons on CD players (and actually several MP3 players I own), making them semi-obvious targets for a quickscreen. File view, I think, is arguable for presence on the quickscreen though.

I'm happy with the current quickscreen, but if it's to be made customisable, I'd prefer it to point to the existing "Browse CFG Files" option.  That would be flexible, customisable and reduce the code size.  (If we really have to, there's nothing stopping us shipping some simple CFG files - "Shuffle Off", "Shuffle On" etc., although I'll admit that's not the best UI.)

right vs select: I personally think "Select" should be the customizable one. "Right" should ALWAYS enter a folder, never insert it, since it's a "navigation" key. Other than that, I wouldn't mind giving "Select" a list of possible options, that list being "Same as right" plus every choice in the Insert / Queue list of options.

Totally agree.  I'd probably keep SELECT=RIGHT myself, because I'm used to it, but I might try using it to Queue.

bookmarks: Yeah, they're at least half broken most of the time, aren't they? Maybe a GSoC project could be removing then, and reimplementing them from scratch with a better UI?

The main problem with bookmarks is that they are Folder-based.  They need to be Playlist-based.  I have an "AllRandom" playlist which I can jump to at any time when I don't really know what I'd like to listen to but I end up reshuffling it each time, when I should be able to carry on where I left off, using a bookmark.  I'd like to be able to listen to my big playlist until I feel inspired enough to go and choose an album, then later return to where I left off.  (Hope that makes some sense.)

The code for bookmark handling is also overcomplicated IIRC; e.g. when I last looked there was different code for bookmark resume and normal resuming.  I'd hope that if bookmarks were always per-playlist, we could manage a dynamic.bmark which would handle the normal playback resuming without any code complexity. Of course, this would only be updated on spinup/shutdown, but that could be true of all bookmarks.

menu: Yeah, I was going to propose a reorganization, but being the lazy sod I am, haven't gotten around to it yet, beyond printing out most of the menu structure. Devcon could be really good for this.

I think we're all agreed on this one - perhaps you could delegate some aspects of it?

Hidden Folders: If a user doesn't want a folder hidden, they SHOULDN'T HIDE IT. The OF quirks that apply JUST to the Sansa shouldn't be coded around. When we have our own USB mode it won't matter anyway.

Absolutely.  Hidden folders should be hidden.  If some braindead OF does silly things, then that's a problem with the OF, not with Rockbox.

Stop: I think Stop and Select should behave identically in terms of what screen they return you to. Specifically, for blind users, "Stop" is more practical than "Pause, then Select" since pausing stops the voice. If they want to clearly hear the name of the song being played, Stop needs to go to the current file. It's been requested an awful lot by them, and I think "Stop, then Menu" to get to the menu isn't too much of an imposition as opposed to just "Stop" getting to the menu, unless you feel like getting Voice to play while audio is Paused.

Yes, STOP and SELECT should behave identically (with the exception of stopping music).  I didn't realise this was broken until recently...

pondlife

[shotofadds]

Hidden folders should be hidden.  If some braindead OF does silly things, then that's a problem with the OF, not with Rockbox.

Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?

[Lear]

as for the playlist viewer.... I agree that its one of the more hidden screens and should be fixed up... first thing it needs to hapen is it to stop using the plugin buffer to store track names (why is this done anyway? doesnt playlist.c have a function to get the track name of any track in the playlist?)

The plugin buffer is used to buffer the filenames, which are (often) loaded from disk when getting a filename from a playlist. If the dircache is enabled, you might get away with not using the plugin buffer...

bookmarks... another probably great feature which is a bit horrible (imo) to use which could do with some TLC from anyone with an idea how to do them better *looks around at the blank stares*

I think it is very good as it is, actually (for me, it's one of the killer features in Rockbox). True, I don't use the database, nor create dynamic playlists, so I don't really encounter the big limitations... 8-)

Oh, by the way, the bookmark viewer also uses the plugin buffer.

(Hrm, had to google TLC. Naughty, naughty...)

[cpchan]

Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?

Unfortunately this won't work at least for the Sandisk players. This is because the brain dead OF rehides it every time.

Charles

[GodEater]

Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?

That only works at installation though. The Sansa firmware re-hides it whenever you connect over USB - so would hide it whenever you transfer new music over.