On Wed, 13 Feb 2008, Dominik Riebeling wrote:
I see one big advantage: we could provide a nice interface and let users select one of a bunch of "standard usecase" presets. Like "I want it similar to Itunes / AppleOS" or "I don't want eyecandy" or such things. And Rockbox Utility is the "housekeeping tool for Rockbox", isn't it? ;-)
Personally, I find these reasons very weak. To me, Rbutil is about "do what you must and then get out of my face".
I see very little use in expanding it to do evertything Rockbox can. And that's mainly because everything we cram into this will add to the maintainance burdon. Also, I must insist that these kinds of feeping creaturisms must be made entirely at the expense of the rbutil code and not making anything in the actual Rockbox code "worse".
I don't know what use cases you guys have and what you do with your Rockbox targets, but I'll tell you that I fiddle with my settings very rarely and when I do change them I use Rockbox and I wouldn't dream of *ever* using Rbutil for it.
I'm not saying I'm against you doing this, I just wanted to make sure I hadn't missed any great use case for this.
About the settings itself: maybe it's a better idea to create the xml file(s) using a perl script from the sources?
You'll again end up with an interesting situation when you have an rbutil with stuff that depends on specific versions of Rockbox...
-- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
