Trying to get a consistent UI for ML
A nice proposal for the menu: http://groups.google.com/group/ml-devel/browse_thread/thread/d1e273de2490f5e5?pli=1
Magic Lantern features are accessible by:
- ML menu
- Shortcut keys
- 550D: right now there's only one for False Color
- 5D: AJ has some more shortcut keys
[]
- 5D: Press Picture Style button
- 550D, 60D, 500D: Press ERASE button
[]
550D[]
- Arrows: left/right move between sub-menus, up/down move between items of a sub-menu
- Actions (initial design):
- SET: default action (change the setting)
- DISP: change the same same setting backwards
- Q: auto-tune the selected setting
- That's why those buttons are named 'select', 'select_reverse' and 'select_auto' in the ML code
Since the menu space is limited, and ML became more complex and customizable, the button assignment was changed for some items:
- HDR:
- SET selects number of images
- DISP selects EV step size
- Q turns this setting off
- Problem: when turning it off, you lose the number of images (pointed out by Nandoide)
- Zebra:
- SET toggles between ON/OFF/Auto
- DISP changes low threshold
- Q changes high threshold
- You can't change the thresholds backward (only forward). Since this is not a setting which is changed frequently, I don't think it's a problem
Problem: this behavior is inconsistent.
Proposal 1[]
A proposal is:
- SET should always toggle the setting ON/OFF whenever possible
- Simple settings (with 2 or more values): SET toggle forward, DISP toggle backward
- Settings with 2 fields:
- Toggle "primary" setting (ON/OFF/whatever) with SET (it should have only a few possible values)
- Toggle "secondary" setting with DISP and Q (back and forth)
- Settings with 3 fields (e.g. zebra and HDR)
- SET turns the setting ON/OFF (or maybe auto); that's field 1
- DISP change field 2
- SET change field 3
Proposal 2[]
Another proposal comes from Nandoide [1]:
Some thoughts regarding user interface. Constraints: we have few keys, we don't have space to put a lot of menu items.
- Use cursor keys (left-right) were possible to change values. It's more "standard" and natural.
- Use SET only to set a value or to change a item to edit mode (see below), not to navigate over the item's domain of values.
- Use Q for quit, see low.
- Use * / / A instead of ON/OFF/Auto.
- Don't mess ON/OFF with value configuration (HDR Bracket). Make another subfield in item.
Navigations, we are positioned on the item to edit:
- On a "monofield" item (ISO:)
- SET lets item in edit mode. In this state all keys "are for the item".
- Right-Left change the values of item (ISO).
- Q or SET fixes the value and exit the editing mode (left-right now readquire the function of displacement for menu headers).
- On a multifield item (Zebras).
- SET lets item in edit mode in the first field of the item (in this case ON/OFF).
- Arrow keys change between * and (SPACE=none). We select * (ON)
- SET fixes the value and quits the field editing mode (state).
- Right cursor send me on next field to edit (ZebraThrLO). (lest right now let me to change between item fields)
- SET enter in field editing mode
- Arrow keys change between ZebraThrLO values.
- SET fixes one
- Q quits the item editing mode
Pressing Q in any field, selects the value and quits the editing mode of the item, not only the field Pressing SET in any field, selects the value and quits the editing mode of the field, not the item. But in monofields items it behaves as Q.
... and we have for free cursor up/down (and DISP).
We can use UP / DOWN to change the step between item values (speed of navegation).
Drawbacks:
- We have more key presses to do some functions (to enter and to quit a item). In a limit case, to activate Histogram we need, once positioned in item, press SET + Arrow + Q. Now only Q. (*)
- Reprogramming
Wheel[]
Another proposal is to use the Wheel to change settings faster. Wheel is not yet decoded (so it can't be used right now).
- Good: it would be useful to change ISO and Kelvin (settings with many values)
- Bad: wheel is already used to change Canon exposure/aperture, even if ML menu is active (and some users actually like this)