Proposition : New Blender Hotkey System

This suggestion comes from two things. First off I heard Ton say (I believe in a blender conference video) that there were no more hotkeys available and that combo keys (like alt+ and ctrl+) would have to be used for future additional features. The second part was inspired by working with an AutoCAD program for a few minutes.

Now I know right off the bat that most long-time users, and for that matter most users of blender in general will probably sneer at me for suggesting this, but I honestly think this idea could speed up workflow once the adjustments were made. It would be like changing all of the letters on the keyboard and learning how to type all over again. If I names these wrong please forgive me. My knowledge of blender is not the subject, the idea is.

What I suggest is that you group certain functions together better than they are. A good example of this is the specials button (“W” key). It’s kind of a dumping ground for functions that don’t really fit in other categories, but allows a quick way to get to each command. Knife tool is turning into another one of these multi-purpose hot keys (“K” Key) A multi-layered hot key would be “SPACE BAR” bringing up a plethora of choices and what I can remember six submenus as well. Now on the specials menu when you type “W” you get a list of choices. The first 9 choices can be hot keyed to by clicking the numbers 1-9 on the number row of your keyboard (top row, not number pad). Why not extend this option? Have each menu or each submenu assigned a number/letter (letters would allow for 26 choices per menu not 9). This would allow for almost nil communication with the mouse and an almost typing style to access the command the user wishes to use.

Here is how with the current setup one could access a UV sphere make command.

[Space Bar],[B],[J],[D],[Enter],[Enter]

This would create in a matter of seconds a 32,32 UV sphere. Below are some images to explain how the letters coincide.

http://www.geocities.com/manonfireproductions/elYsiun/MenuIdea.png

The next part of this idea would more than likely be a python plug-in. Have a text box available with blender commands as text commands or shortcuts. In AutoCAD you can actually “type” out your objects, and with precision to its sizes. An example of this to create the same UV Sphere “could” (but not necessarily) look like this.

Create Mesh UV 32,32

This one simple command could make the same UV mesh quickly. These options for user interaction could help AutoCAD users find a quicker way of moving to blender. I personally think that the more simple communication is the quicker and more accurate a system becomes. A good side bar would be that the text command box could be customized for shortcut commands and even languages! I could make and save my own command for the above create mesh. Like this:

CU32 = Create Mesh UV 32,32

Now every time I the user type CU32 the command line understands the shortcut I made up. I could even make 20 of them quickly 2 blender units apart (from center) like this.

CU32 Dup +x unit2

This would make my shortcut command [Create Mesh UV 32,32] duplicate it along the X axis in a positive direction and do this command every two units.

I understand fully that the structure of the command line language might not work out in this fashion. I have used what little programming I know to create a demonstration of the tool. Hopefully Ton and the others find at least the direction of these ideas compelling and explore their possibilities.

Thanks for your time, and any suggestions you might have.

JABayne

My oppinion:

First I just want to say that I’m an “seasoned” ACAD user (r13-2000) too so I can relate to your workflow. However, I’m more used to using a huge (not sure about the exact size, but about as wide as the keyboard and almost as deep) digitizer board, so I mostly used the keyboard for numeric input and the occasional macro. I had a real headache relearning with mouse and keys when they dropped support for that hardware in ACAD 2000. I think it was because of health issues since they figured out that hanging over an electro-magnet 8-10h/day isn’t all that great ;). Also it caused neck/back-injuries since one always had to look down when selecting tools. But boy did I love that piece of equipment…

Good and bad about your ideas (imho):

Good:

  • Multiple ways of interacting (key, icon, command) with the software is always a good thing in my book. And afaik, using aliases and macros through console-commands doesn’t break anything.

  • More grouping (and perhaps more context-sensitive) use of command is a valid possibility. For example: Shift-O (subsurf ON/OFF) could be placed in the special menu, just like smoothing are atm. Since they seem related (both logically and following the workflow).

  • More button sequences. This is already utilized to some extent (Grab for example where pressing G twice switches to local orientation etc). I would love to attach a snap-action somwhere in that sequence. Ah well, one can dream at least…

  • Like the idea of expanding 1-9 to the whole alphabet, although it might be cumbersome if the numbers of levels are too many. Also, I think I would prefer a QWERTY-oriented list instead of an alphabetical one, since I’m guessing that remembering the button will be easier than remebering the letter and THEN try to find the button.

Bad:

  • Conforming ALL commands to centralized access menues won’t be to smart. Blender is, and has always been, about speed. Having fundamental tools one button press away is one of it’s strengths. Replacing G-key with a “Grab-mode” is a huge step back in my opinion.

Something that you haven’t mentioned that I, personally, would find useful is some way to access scripts easier. A menu for scripts on the Space-menu would be nice (especially a context sensitive one that masks out scripts that dont apply to the current state of the program).

I did see somewhere that there was a quick menu link for scripts that floated in the 3-d window, and by clicking it you could quickly access a list. Making flags on the scripts so that they were function sensative would be a nice touch.

As far as conforming ALL of the commands, that might not be the best idea even though I was hinting towards that way. However, grouping things and learning the new shortcuts would be almost as quick. More than likely it would be a good balance of the two. In the end what I am getting at is that it would be nice touch to have things a touch more organized, quick to access when there are many choices in a list, and have a command line interaction for a more “programming” type approach.

The more tools the better.

Thanks for the response and positive feedback.

JABayne

As far as a command-line approach goes, I think the python guys have been playing with this idea for a while. Of course, as I understand it, implementing it is a nontrivial task.

Regarding re-organizing hotkeys… not a huge fan of it to be honest, but I can see where it may become necessary. However, I think your proposal is an overall workflow impediment. Heirarchy is great for organization and finding things, but it’s hell when you’re actually trying to get work done, in my experience… especially when you’re using what sounds like a modal concept to traverse that hierarchy.

What it really comes down to, though, is my love for GKEY, RKEY, SKEY, EKEY, and AKEY (as well as XKEY and BKEY, to a lesser extent). I’m quite fond of the mnemonics and keyboard location of that cluster, considering how frequently they’re used). I’ve used quite a few apps (3D and otherwise) and I’ve always liked those particular defaults as they’re presented in Blender.

The hotkeys could do with being changed IMO. I will probably get lost at first with having the keys messed about but as they are, they don’t make sense. Every time I press g, I think, why the hell am I not pressing t (translate) or m (move). I’m of course referring to keys being chosen to signify the command they invoke just as r (rotate) and s (scale) have been.

Another thing I think should be done is to change the layers system. The numbers 0-9 at the top of the keyboard are being wasted. If the layers were like layers in every other program I know that has layers, they would be a list like the outliner view. I keep pressing a number by accident and moving to an empty layer and I can never remember where I put everything because they have no names. Even if the outliner assigned objects an attribute that meant which layer they were in and you could list the outliner by layer to activate or deactivate each one. That way you don’t need two displays.

Then you get those extra numbers up top for other stuff.

What I think should be the general rule for hotkeys is that if the command is a tool then it shouldn’t have a hotkey but should be accessible via a menu or preferably a tools palette. This tools palette could have a hotkey.

So say I wanted face loop cut, then I could press p for the tools palette (I’ve used i for isolate instead of p for separate and k for key instead of i for insert key). The palette that appears would be a floaty window in 3d view that had all the mesh tools or a subset of them. Expanding this idea, you can even get rid of the entire interface and just have a 3D view. No more tabs. How many tabs are there anyway? 7 including the physics panel so all you need to do is use the numbers 0-9, which I freed up by moving the layers to the outliner.

By making floaty 3D panels, you don’t have to worry about fitting them to an interface so no need for the drag and drop tabs and no need for any headers. The palettes/windows that open up could have scroll bars and resemble Maya’s attribute windows.

That kind of thing would be useful when dealing with lots of bones.

The trouble is that there are so many ways to tackle this problem and none will be perfect and they will all require a great deal of work.

I’m pretty sure you know this, but for those who don’t, G is for Grab.

I see what you’re saying about layers… and it’s probably a nice addition. I have to put a nod to the speed that the current layer… er… “system” has. It’s great for working fast (and I use the number keys for layers all the time). If there were a way to keep that speed while adding functionality, it’d be nice. But I’m not hurting on that front ATM.

Ain’t that the truth!

The space menu should probably just get numeric access just as most other menus get. Using letters would really jump all over the keyboard and be inconsistent with current blender style…

LetterRip

Hello!

Is there somewhere a new build of Positron for Windows out, something like CVS or Nightly?

Ciao,
CMB02 8)

Uh…wrong thread? :o

To clarify: Proposition != Positron. Yep, you guessed it, reading helps.

https://blenderartists.org/forum/viewtopic.php?t=43343
^That’s probably what you’re looking for.

Damn :expressionless: :expressionless: :expressionless:

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. :slight_smile:

Forgive me if I’m misinterpreting the point.

If I read this correctly, this would cause the problems if you ever added a new item to a menu, as it would potentially cause the items to ‘shift’.

So if you’re used to adding the monkey all the time using B>J>J (using the method in your post) but now the developers add ‘teapot’ and ‘torus’ to the menu. Unless those items are always put at the end, it will cause other items to shift down.

This means potentially re-learning keyboard shortcuts every release.

I would think a Wings3D style approach of easily remappable keys would be cool, though.

Duoas,

good post - lukep is doing a design doc for the event handling refactor now.

LetterRip

Agent 86.5, good point, never thought of that one. Oh wells, it seems I have hit a nerve at least in the menu/workflow structure of things. Hopefully the designers can work out something. I still think the line text command thing would be a great addition.

JABayne

JABayne, Agent 86.5
That’s kind of why I prefer 0…9 instead of A…Z. To a non-programmer, it’s much more obviously just an enumeration.

The way the menus are currently designed you still have to look at them before selecting. Items within can move around at any given release but they are still numbered 0…9. (I tend to use my mouse when the menu pops up, but I suppose that’s just because I’m looking at a menu…)

Giving shortcuts to the spacebar menu isn’t an entirely bad idea though. For a menu like this though, I’d pick specific letters out of the words. (This is OK since there’s nothing to conflict. Changing language shouldn’t affect it either. [edit]That is, the letter keys used can change to match the current language.[/edit])
http://clam.rutgers.edu/~mgreer/blender/spacebar-menu.png

LetterRip – Glad to hear it. If he or you want any input I’ll be glad to share what I think. (In case no one has noticed, I’m kind of a UI/Design freak – I remember what it was like learning to program with crappy tools and how much I missed the good ones when unavailable. Just wish I had a piece of paper that said I knew what I was talking about after all the study I’ve put into it. Then fellow programmers/bosses would have a harder time giving me stupid looks when I suggest UI improvements… ;>)

Also check out current CVS, the default space menu is now a regular linear list of menu items instead of the wide rectangle row and columns.

LetterRip

Hmm, yes, that’s a much better solution. Then the default menu hotkey system is in automatic use and the menu itself conforms with everything else.

/me hits self on head for not thinking of that…/

some points to note :

  • what i’m starting is the low-level ghost events refactor, not the events key. they will be part of a separate work at a later stage
  • context sensitivity is important yes, and will be present to even include modalities.
  • muscle memory is important so the existings memomnics and paragdims must be preserved as much as possible. that means :

**** from a technical point of view, multi-letters command is bound to out of sync if you dont enter a modal state. Modal state is the root of many evils and blender should stay away from this.

**** we have around 80 keys and 8 combinations of modifiers. so even with a single letter command we dont run out of key if we carefully reorganise them.

**** main one keys must be kept (G,S,R,E,A) & as many as possible of others too

**** the 0…9 system also

**** new system should allow not only for customization, but also that more than one shortcut launch same func or eg via python.

**** not all functions need fast access. typically adding an object can be done via menu, but a repeating task like extrude must be fast.

I just remembered something I forgot to mention before.

Hotkeys should be user-definable. I’ve done this before in other apps and it is very easy to do and nearly as fast to operate as hard-coded stuff (one or two function call’s worth of overhead --fast enough that the user won’t notice any difference).

There should be a core, hard-coded (static) table listing the default keyset, then another dynamic table to hold the difference. If there’s a fixed size to the keytable (say, we’re not considering two- or three-key sequences), then just have the dynamic table initialize first with the default then with any user-defined keys and use it only when performing key look-up. If there’s not, the dynamic keytable should only hold the difference between the default keyset and the user-defined keyset.

This would allow, for example, users who prefer using Ctrl-W to exit instead of save to change it to their preference.

It would also allow the programmer to more easily maintain keymappings.