Rockbox mail archiveSubject: Re: [RaaA] Weekly status report
Re: [RaaA] Weekly status report
From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Fri, 28 May 2010 20:23:57 +0200
On Mon, May 24, 2010 at 01:33:03PM +0200, Thomas Martitz wrote:
> 1) io.c, currently the simulator hides the rest of the filesystem and
> only shows the current working dir in the file browser (by wrapping file
> I/O functions). I think we don't want that for RaaA but I also doubt we
> want to expose the entire filesystem. What came into my mind was
> (assuming Rockbox is installed into some program dir) that the file
> browser would show the program dir (i.e. the working dir) where .rockbox
> sits and to show $HOME via a "mounted drive", e.g. similar to how
> microSDs are handled currently; this way you could easily access the
> music folders (and pics, videos) independently of the installation dir.
> However, that doesn't work for music outside the $HOME dir. How do we
> want to handle this cases? We could use the ability to name the .rockbox
> dir differently or change the "root" directory dynamically.
I think it's actually more complicated than that. This will depend on
the host, but on some systems you won't want settings and binaries in
the same place if you can avoid it, and you might want to have the
default theme with the binaries and extra downloaded themes with the
settings. I'm not saying support for this sort of thing should be
implemented right away, but it's probably goot to keep this in mind.
For now I'd say we need the place where .rockbox is located as the root,
and a set of user-configurable extra directories (possibly defaulting to
$HOME, although this might again vary per target). That allows the
"whole FS" usage, and it allows the "music directory only" usage.
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. KernighanReceived on 2010-05-28