[Bf-taskforce25] Keyboard Shortcuts Proposal

[William Reynish]

Hi Ton,


On 22 Jun, 2009, at 2:13 PM, Ton Roosendaal wrote:

> Hi,
>
> Setting apart personal preferences or conventions, I really would
> prefer to see a proposal for how to use keys optimally. Learning you
> only do once... and for learning situations you can make a special  
> easy
> and limited map anyway.


Regarding optimal use of keys: I touched on it briefly, and I'm sure  
there is more theory to explore, but this is what I'm thinking:
-should be as consistent as possible. (Consistency within the app is  
well established as being positive, but don't forget consistency  
across other apps too)
-should be as direct as possible (whole point of shortcuts are that  
they are fast)
-to make them easy to remember, use some logic, like starting letter  
of action, or even the letter symbol itself (as Y for split). This is  
not always possible though.
-take into account the position on the keyboard. Right handed people  
find it easiest to use the left part of the keyboard.

These things could be taken into account even more if we were to  
create a new key layout from scratch. But with all the UI changes  
already happening in 2.5 I thought it best to do a 'mild' update of  
the keymap - one could be much more daring!
This is mostly just a cleanup of the old keymap, not an attempt to  
build a whole new one. And actually, aside from smaller  
inconsistencies and old cruft, the old keymap was fairly good, so no  
need to start all over.


>
> As starting points for an optimal keymap you can really assume:
>
> - 3 button mouse with scrollwheel
> - access to 12 function keys
> - but avoid special character hotkeys (anticipate multi language
> keyboards)

I'm not sure everyone has a scroll wheel? We can use it, of course,  
but perhaps not as only way to get at certain functionality.
Function keys likewise.


> For consistancy, mouse usage rationales van be split in three (yes  
> from
> Raskin!):
> - actions (buttons, handlers, manipulators, pickers, menus etc)
> - view manipulations
> - selections

You could also split it like this:

-selections (objects, vertices, buttons, handlers, pickers, menus etc)
-view manipulations
-other stuff (could be context menu)

Selecting items in a menu, or selecting text is not that different  
conceptually from selecting objects or vertices.

>
> (Contextual menus can be on any mousekey or hotkey, in Blender context
> is not depending on mouse positions, so it doesn't require mouse input
> by definition)

Could be, yes. Space key can also assume this role. If so, right-click  
can be used for things like setting the 3D cursor.


> It's a weak point in other 3d programs that the 3d widgets are in the
> way for selection; forcing you to turn them on/off in cases. It's also
> planned to explore custom widgets in Blender more, like direct mouse
> inputs for rigging handles, lamps, operator redos, etc.
>
> Putting all selections and all tools (transforms, lasso, knife cut,
> loopselect, borders, etc etc) in LMB is possible, but is that really
> optimal? I think it's worth some really good thinking here.

Indeed. This also intends to start a discussion. Regarding RMB select  
it's a balance between the advantages it may have, and the standards.  
The more non-standard we go, the harder it is to learn, and the harder  
it is to fluently jump between multiple apps, which I see as very  
important. There are very few situations where I see this conflict of  
actions, but in that case you could also define a click-through  
modifier for selecting things behind stuff. This is also useful for  
selecting bones while painting etc.

But yeah, this is something to watch. When we do get keymap editing we  
can try out ideas, see what works and what doesn't.

It's also good to think about tablets and laptops where right-clicking  
is not always that easy and direct.

Cheers,

-William