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/