From: Björn Stenberg <bjorn_at_haxx.se>
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

Received on 2004-01-11