Rockbox General > Rockbox General Discussion
Re: Constuctive suggestion/Attracting more users/Install theme with first launch
JdGordon:
A default set of settings is already used if config.cfg isnt there, but the defaults are hard coded, there is no reason why those defaults couldnt be different for different targets, just needs someone to come up with good workable defaults.
Spug: iirc it was planned to eventually move that file into .rockbox, I dunno why it hasnt happened yet tho.
Llorean:
On many players you can put rockbox.target IN the .rockbox folder and still have everything behave normally (iRiver HXXX series and iPods at least).
pabouk:
--- Quote from: jdgordon on January 24, 2007, 07:12:06 PM ---A default set of settings is already used if config.cfg isnt there, but the defaults are hard coded, there is no reason why those defaults couldnt be different for different targets, just needs someone to come up with good workable defaults.
--- End quote ---
I think that some default settings should be always hard-coded into the kernel so the firmware can run without any additional files but I prefer the concept with default.cfg (in addition to the hard-coded settings) which is much more transparent. With default.cfg the default configuration could be changed without recompiling the kernel and the user can easily check the default configuration using just a text viewer. It would also allow comparison of current and default config using diff or some plug-in.
I see just one potential problem - the reset settings function. It should probably load the hard-coded defaults in order that the user could always reset to a know configuration (default.cfg could be changed).
Excuse me for off-topic but I am very curious about this:
--- Quote from: Llorean on January 24, 2007, 02:09:14 PM ---My thought was that there could be a default.cfg and a current.cfg. If current.cfg does not exist, default is used, but user's settings are stored in current.cfg instead. So, a clean install gets default.cfg, but user settings are never overwritten because current.cfg isn't included.
Then you can easily package target-specific settings, that way.
--- End quote ---
Llorean repeated almost exactly what I wrote in the previous message (with a new good idea of renaming config.cfg to current.cfg):
--- Quote from: pabouk on January 24, 2007, 10:11:07 AM ---The current code does not really support default configuration in a file. I think that Rockbox should check for the presence of config.cfg and only if the file is not found it should load default.cfg which could be easily shipped with the firmware.
--- End quote ---
I know that my English is bad but is it so bad that my messages are not understandable?
Llorean:
Rockbox cannot run without the .rockbox folder anyway on most targets as the codecs are needed. The Archos targets are an exception. But only the current defaults need be hardcoded, target-specific ones can be in the file.
The user shouldn't ever change default.cfg. There's no reason to. If the current.cfg exists, you'll boot into it without it ever reading the default.cfg file, so there's no concern regarding resetting the settings. And there will still be the hardcoded defaults, which aren't target specific, just in case.
Basically, boot would look like this:
Does current.cfg exist?
Yes - Load current.cfg
No - Does default.cfg exist?
Yes - Load default.cfg
No - Load the current default settings.
When you shut down current.cfg is saved. Default is never changed unless the user manually opens it in a text editor, and it's never loaded unless current.cfg doesn't exist.
JdGordon:
I dont see the point of default.cfg... everything that can be done in it would be easily done in the code, with the advantage that "good" settings are applied if .rockbox doesnt exist, and eliminates the question of what to do when the user resets
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version