[Bf-taskforce25] Keyboard Shortcuts Proposal

[GSR]

Hi,
william at reynish.com (2009-06-22 at 1148.13 +0200):
> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/UIKeyboardLayouts

- About the keys maps, 2.49 and SVN:

I am unable to find Save Render or Save Screenshot. This one also
missing in 2.49 (and some other Fx keys combos), they should be there,
it is "what we can already do". Some other pointed drawing styles
(Zkey and combinations) are pretty common to use. OTOH, will "Occluse
Geometry" finally get a key (I bet many just workaround with Zkey)?
How does "All viewport display options are now accessible by pressing
the D key" differ from all 2.4x?

And also I wonder what will happen with layers? Some people use them a
lot to organize the working view but the proposal uses num keys for
mode (BTW your 2.49 image has lacking or wrong combos about them, no
Alt version for layers 11-20 and "key below escape" is activate all
layers). Maybe a popup like Mkey one, where the numbers will work for
the current 3d view?

Wait a sec, I found "key below esc" it is "near z" based in the
funtion... could you use a better font and a normal layout? Dots,
commas and even some symbols in the num pad can all be described as
fuzzy dots. And the mac layout does not help much either (ref photos
for usa kbd show other thing, like "key below esc" being really below
it, so it is hard to guess what kbd the pngs represent, and I guessed
mac because it has option key). Figuring a way to document double mod
bindings (eg Shift+Alt+something) would be useful too, so we do not
forget them, even if such bindings are non engouraged in 2.50, as
there are a handful of cases; and some less with three, but they exist
too.

This reminds me another interesting point that should be solved for
once: localized keyboards. The most common approach is avoid or
minimize usage of symbol keys; sticking as much as possible to
numbers, letters and some other common things like arrows and so on.

View selection with Shift+num is a hack for laptops, so I hope it
stays that way instead of also being forced into full keyboards (or
people that do not want it in laptops) as it means things are
impossible, like multiselect modes (eg vertex and edges) and in
general just uses keys that not everybody is going to use. Previous
system even has physical relation of 3D world vs keyboard layout.

The page text says copy and paste is standard, but images do not show
it. Undo is also a hot topic about standards.

- About the mouse buttons and other pointer issues:

How does new mouse layout allow click based extrude? Or 3d paint or
sketches or grease?

You should also clarify what you mean with tablet. A tablet like ones
made by Wacom, Genius, Thrust, etc? Or a tablet PC which lacks
keyboard? I hope the first, as the second forces a lot of things.

- About the pie menus:

Are we going to get that, yes or no? The reply makes a whole different
world about all the key talk above; I noticed this with the view
selection case: depending if pie menus are avaliable or not, we have
to figure workarounds for laptops, or we could keep the numpad as is,
and get a pie menu that does it, for laptop and people that dislike
"flying" the hand to the numpad.

And then you can repeat this logic for many other things, giving one
key to trigger a menu with 2-8 options (draw style, pivot, PET mode
would be good cases) or having to figure how to fit 2-3 functions in
the keyboard. Plus we could find a nice way to cancel them, which for
now seems undecided; I would go for same key than triggered, Esc and
click in the start position, as the old "shake your mouse" gesture
becames impossible.

Lets assume they get in.

Previous studies suggest menus should fit in 2 (sides), 4 (add up and
down to the previous) or 8 (add the 4 diagonals), Matt's tests follow
this. Those studies found that the "adds" are slower than the previous
method (up slower than left, diagonal slower than up), and leaving
empty spaces is better than doing X zones of 360/X degrees (they got
the surprise when testing 7 vs 8). So taking these rules from the
start allow good placement based in priorities and future expansion
with no or minimal relearning in case of adding more items.

But we can not go happy using them for everything ignoring what makes
them what they are: things have to be limited in number, and the
modifier keys should be done first (or multiplicate the entries to
cover such things like "expand edit mode from vertex to vertex+edge").

If there are many entries, menus have to become multilevel. 8 is one
level, up to 56 with ideal conditions force two levels, 8 directions
open submenus with 7 items each, etc. Another thing to take into
account before jumping into pushing 12 functions in a menu.

It is good to know the limits and plan for things that will stay
inside them for a long time. So pie menus are out, we better think
harder about bindings, and if in, we better put right bindings and
functions the first time.

GSR