[Bf-committers] ED_area_headerprint guideline?

[Campbell Barton]

Agree that this should be improved,
The problem is that whats there now is hard coded so the keys will
show incorrect for anywith with a modified keymap.

IMHO there really should be an API to take a modal keymap and
stringify each item to display in the header... (or possibly a draw
callback which can show key-outlines like we have one mediawiki to
denote key shortcuts more clearly).

I'd be ok to work on this at some point, though we have so many UI
tasks open now I dont want to add more just yet.

On Thu, Feb 13, 2014 at 3:32 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
> Hi all,
> I was working in the headerprint for the walk and fly navigation and I
> was wondering if we have a standard/guideline for the operators
> messages.
>
> A few examples showing some inconsistency:
>
> Knife Tool operator:
> ================
> "LMB: define cut lines, Return/Spacebar: confirm, Esc or RMB: cancel,
> E: new cut, Ctrl: midpoint snap (OFF), ..."
>
> Vert Slide operator:
> ================
> "Vert Slide: 0.001, (E)ven: OFF, Alt or (C)lamp: ON"
>
> Grease Pencil Erase Session:
> ========================
> "Grease Pencil Erase Session: Hold and draw LMB or RMB to erase |
> ESC/Enter to end"
>
>
> That made me wonder about a few points:
>
> * When to use "/", when to use "or"?
> * When to use "," when to use "|"
> * Should we have the shortcut mixed with the action (e.g., (C)lamp)
> whenever we can?
> * Should we have the value (ON/OFF) outside parenthesis?
> * Why to omit the cancel/confirm actions in some cases (vert slide,
> bisect, ...) but not in others (knife)?
> * Why to use  shortcut:action (e.g., "LMB: cut") instead of
> action:shortcut(e.g., "Cut: LMB"). 2.49, Fly Navigation at least, was
> using the latter.
> * Should we always show the value (ON/OFF) for the actions that are
> enabled/disabled with press/release (e.g., Ctrl in Knife Cut, or Shift
> in the walk navigation)?
> * ... probably other questions to be pinpointed, I didn't look to all cases
>
>
> I'm not volunteering to tackle this, but I think this is something the
> UI team could/should take a look. It would be nice to have a guideline
> for this somewhere.
>
> Cheers,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell