From: c0utta fish <c0utta_at_hotmail.com>
Date: Mon, 12 Jan 2004 20:35:57 +1030

Björn,

Thanks for your feedback. I agree that configurable quickscreens should not
just be shortcuts to menu entries either. I plan to make all sorts of
things configurable - starting plugins, running config/wps files, specific
settings (such as setting backlight to 10 seconds, setting volume to 65%
etc) as well as shortcuts to menus.

Unfortunately, I believe "everything" is reasonable for F2 screens. There
will always be one crazy person who wants specific control over the peak
meter maximum setting - why should this guy be excluded ? If we don't do
this then we have an unsatisfied user community and a plethora of patches
allowing for settings that we decided were unimportant to us.

My experience with devices with limited user entry is that you should always
aim for unlimited configurability. If designed correctly, unlimited
configurability is completely transparent to the novice user, but allows the
"power user" to squeeze as much as possible out of the software. You may be
interested to know that I'd class myself as a novice user - I purely use
Rockbox to play MP3's. But, as a novice I still want to be able to have
complete control over my Rockbox settings. If I can't easily set "Follow
Playlist" then I'm unsatisfied.

All I can say is trust me! Let me produce my first working prototype in
about 4 weeks and I'll then spend some time on IRC convincing you that I'm
doing the right thing. Just to whet everyone's appetite, I already have
Rockbox reading the F2 menu out of \.rockbox\f2.map and being able to
execute settings. At last, my dream of being able to easily set "Follow
Playlist" has been realised!

Cheers,

c0utta



>From: Björn Stenberg <bjorn_at_haxx.se>
>Reply-To: rockbox_at_cool.haxx.se
>To: rockbox_at_cool.haxx.se
>Subject: Re: F2 Configuration
>Date: Sun, 11 Jan 2004 17:20:43 +0100
>
>c0utta fish wrote:
> > To do this successfully, I need to add an action code to every menu
>entry
> > in F1 (i.e. add an action element to the menu_items structure in
>menu.h).
> > My long-term plan is to separate actions from buttons and this is the
>first
> > step.
> >
> > I have also added a key handler to the menu system that allows key
> > assignments to be more flexible. For example, my above suggestion about
> > using F2 within F1 to assign a menu item uses this key handler to
>execute a
> > function stored as a pointer. Once again, this is a part of the plan to
> > separate actions from buttons.
> >
> > If anyone violently disagrees with the above then let me know, because I
> > don’t want to start this major re-organisation.
>
>I'm not sure I think your approach is the best way to do this. It certainly
>is a very flexible way, but I'm unconvincet it will accomplish what we
>really want.
>
>I don't think the configurable quickscreens should simply be shortcuts to
>menu entries. That's too slow to use, at least the way the configuration
>menu entries work today (enter setting, change value, exit setting).
>
>I think we should start with making a list of what is reasonable to be able
>to put in the configurable F2 screens. (And "everything" is not a good
>answer.) Then, looking at this list, we can think about the best way to
>implement it.
>
>A little background:
>
>"Total configurability" is nice in a theoretical and geeky way, but it
>really doesn't help end users. Drawn to it's logical conclusion, total
>configurability means replacing most UI code with an interpreted script
>language. This way, every single user can rewrite the Rockbox UI to their
>liking.
>
>Experience from several past projects that have tried this approach,
>however, tells us that the overwhelming majority of users don't want the
>complexity such a solution gives. Most users don't want to program their
>tools, they want options and settings.
>
>--
>Björn

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to
http://ninemsn.com.au/mobilemania/default.asp
Received on 2004-01-12