The keyboard handling in Blender is definitely something that needs improvement.
The original design docs suggest that keys should be the same for each type of space (within reason, of course). However, as should also be obvious, each space has a certain degree of customization (or ‘context’).
As Blender has grown, the context has overgrown the keyboard.
The first problem is that the Blender UI doesn’t specificially catagorize keys properly. There are three types:
-
super-keys
These are application-level keys, conforming to the original Blender design idea. They work no matter where you are. Examples are F1, F2, Ctrl-O, etc. These are not affected by context; they work the same no matter which space contains the mouse cursor.
-
context-keys
These are keys whose function is dependant, at least in part, on what space contains the mouse cursor. An example would be E (3D View --> Extrude, UV/Image Editor --> LSCM Unwrap), etc.
Something I have found annoying that would fit here is the I key. If I want to insert an animation key, the mouse must be in the 3D View. It won’t work in the Action Editor (but it should!). I haven’t thought too hard (well, at all) whether using I would make sense in other spaces, but for at least these two it would make sense that it insert an animation key.
Notice how it isn’t a super-key; using I wouldn’t make much sense in the Outliner… More directly, the actual function of keyframing is a context-specific thing to do.
- menu-keys
Keys you press to perform a menu action. Already noted are 1…9. So W,0 does a Subdivide. The 0 is a menu-key.
Menu keys are a form of context-keys, only their context is the menu (which appears in the context of a space).
This suggests a number of things. The first is that a key sequence is a valid input mechanism. WordStar users have known this for 20 years while M$ and the rest of the world keep trying to make our keyboards dumber. Blender, as noted by JABayne above, already kludges a number of functions this way. The W key is a prime example. This is not Bad, but W comes precariously close to being a dumping ground for random commands, albeit common ones (I use W all the time).
A valid key sequence is 1 to three keys, with an optional shift|ctrl|alt modifier on the first only. Note that this does not interfere with modal selections, like pressing Alt-B for loop select and then holding shift to toggle additional loops.
The second is that there is a hierarchy to workflow. The keyset is most effective when it matches that hierarchy. Blender does a pretty good job, but it has also drifted considerably (more on this in a moment).
The third is that there are plenty of key shortcuts available, even in a complex program like Blender. A quickie calculation for two-key sequences:
36 alphanumeric keys (primary key)
x shift | ctrl | alt (any combination of bucky bits) = 7
x 36 alphanumeric keys (secondary key)
= 9072
Thats nine-thousand available key sequences (including one-key sequences). We don’t need but a fraction of that.
Blender has a couple of problems to overcome.
- toets.c
Yes, I know. Don’t hate me. The code here was a good start (I would probably have coded the same thing), but it is insufficient to the task now. It’s problems are two-fold:
(1) It doesn’t recognize context.
(2) Not all keypresses are processed through toets.c.
A better way would be to fill toets.c with linked key functions. Those of you familiar with callbacks or signal/slot function mechanisms (event procedures) already understand. The flow should run thus:
(toet_func *)toet_handler( ... ) // function pointer explained momentarily
toet_dispatch( key, context )
capture keys that cannot be redefined (if any)
dispatch to the context key handler
toet_x_handler( key, context ) // where x is the context, such as 3d_view
handle keys specific to this context
else dispatch to the global key handler
toet_global( key, context )
handle the super-key
The toet_handler() is normally set to point to toet_dispatch(), but when a key-sequence is begun it is modified to point to the appropriate handler. (There are other ways of doing this, but this works well.) Once the key sequence is completed the handler is restored to toet_dispatch().
Note the order though which the key parsing flows: bottom-up (as it were). This gives a context the power to maintain its context over any global key. For example, the text editor could now implement the Ctrl-Left/Right Arrow --> Word Backward/Forward function that everyone expects in a text editor without that ‘switch screen’ functionality jumping in annoyingly.
[Coders, you know how to read examples, so no flames for trivia, OK?]
- the point of this thread
Some new, serious consideration must be given to the key assignments in Blender to update its current (failing) condition. It will restore an open keyboard layout (no more “we’re out of keys!”) and synchronize with the revolutionary space layout which we all know an love.
Context is not a bad thing. Trivia is.
It’s entirely reasonable for S to mean ‘scale’ in every area containing some object you can scale.
Zarf earlier disagreed with me on this point, but I think important keys should have either some strong mneumonic association and/or spatial orientation. Blender already does this to a some degree (S - scale, I - insert, R - rotate, G - grab, U - undo).
I disagree for using ordered letters for menus (I’m more partial to the current 0…9 system), but that’s again a matter of debate.
The point is that the key sequences should be:
- convenient to the left hand
- mneumonically or spatially recognizable
- ordered for ordered things (menus/lists)
Some things that bug me (and noted in the Blender Coding/UI Design forums), which would be fixed by the suggestions above:
- Pressing Esc while in a line edit box when running a script immediately terminate the script (bypassing the expected behavior of only terminating changes to the line edit)
- Random bucky bits used for similar things (Alt-B, Shift-R)
- hmm, that’s it [for now, mua ha ha haha]
I suppose I’ll shut-up now. I haven’t given this tons of thought, and there’s always room for improvement. In the other forum, someone suggested that Blender is for programmers. When a program is written for programmers it is usually written very poorly. Those of you in the software industry who’ve had to deal with some wiz-bang programmer (self-taught reading books on the toilet) who has no concept of how users look at his world understand the fallacy of ‘programming for programmers makes good programming’.
(For example, those of you who use editors that trap the cursor to the available text in a line. You’ve been lead to believe that it’s a ‘feature’, to know where the text ends. That’s bunk. Editors do it that way because it’s easier to program that way. Ever try to edit a file with alternatingly long and short lines of text. Annoying isn’t it? A little extra effort on the interface would let the cursor float past the end of the line and obviate all the problems that come from constraining it --like jumping away from what you’re editing constantly-- without loosing anything --find the actual end of the line by using the ‘goto end of line’ command.)
UI Design is everything.
I’ll really shut-up now. 
