[Bf-committers] 3D Cursor and Border Select

Sean Olson seanolson at gmail.com
Mon Feb 27 18:37:14 CET 2012


*On the proposal for drag select/double click 3d cursor:*
I have taught some  Blender courses as well, and the students, who were
well versed in other packages, were 'annoyed' by the 3d cursor - in fact,
they wanted to hide it from view completely.  I personally set the 3d
cursor to the 'q' key, and set right click to be the vert/edge/face select
- this is much more ergonomic than ctrl-tab all the time.  (I use left
select mode as I am a tablet user as well).  I think that having the 3d
cursor on double click is a good idea, but a past argument against it is
that it is hard to place anything with 'precision' with a double click.

*On the philosophy of Blender Key setup:*
As far as I know, the philosophy of Blender Key setup is, "One hand on the
keyboard, one hand on the mouse".  Additionally I think it is fairly
unspoken but universally agreed upon that we are going for ergonomics and
speed of use.  The problem is, the current key setup violates those rules
all the time.  I think it has turned into, "well, what keybinding is free?
 Ok, I'll put it there."  There are also some very funky things going on if
these are the rules we are holding our selves to. Blender makes heavy use
of the numpad, but the numpad is on the right of most keyboards.  You have
to take your hand off the mouse or reach across the keyboard with your left
hand all the time to hit the numpad keys!  This is especially problematic
for tablet users as dropping the pen is much more difficult than letting go
of the mouse.  In fact, I bought a special keyboard to solve this very
problem that allows me to put the numpad on the left side of the keyboard.

*On keybinding editor:*
The keybinding editor has made great strides and it one of the most
flexible out there (rivaled only by modo I think)  but it is rather
daunting to new users and old users alike.   Some serious UI design is in
order to make this tool much more usable.  For one, a way to look up
current keybinds by what it is bound to would help a lot (look up ctrl+R).
  Additionally a way to see or a warning for duplicate bindings is in
order.  It's very frustrating making a new bind, realizing it does not
work, and searching through that whole list for another function with the
same bind.  (And I only know to check for that from experience, a new user
will have no idea what is wrong, and will just give up on key binding in
frustration.)  Currently, the keybinding editor is a 'advanced' user tool.
 New users, who need it the most, won't know the first thing about how it
works.

*On included keymaps:*
I know that there have been multiple attempts to get a 3dsMax keyset into
Blender that have failed.  If I recall, they failed because certain keys
from the max setup 'erased' other functionalities of Blender.  I'm
frustrated by this decision as I don't see the logic behind, 'No keymap is
better than a partially working keymap'.  I feel that if this was included,
it would ease the transition of new users, and there would be real feedback
on how it needed to be updated to become truly top notch.  I feel that we
ran 26.75 miles of a marathon in building the new keymap system, and then
we sprained our ankle and quit on the last quarter mile.  Getting those
alternate key maps into trunk really should happen.

I agree with the decision that included alternate software keymaps should
focus on 2 things: viewport manipulation (pan, rotate, zoom) and object
manipulation (translate, rotate, scale).  These are the things that really
frustrate not only new users, but users using multiple packages.  Try to
model something in Blender, take it into Zbrush for some sculpting, and
then onto maya for some animating.  Even if your brain can adapt to the
different key bindings, I bet there is a minute or two of 'readjustment' to
the current package.  I don't think deeper functionality needs to be
keybound and it often would not work as different packages work differently
(And that is what the search box is for, right?).  Additionally, the reason
for jumping between packages is to use the package for unique functionality
that it provides - so you are not going to expect the key bindings from a
unique functionality to match between programs.

* On the best place to discuss UI proposals*:
As my rant has proven, UI and UX discussion can become long winded.  I know
some are very passionate about the subject and others could care less.  Is
a new mailing list in order? (bf-UIDiscussion)


In short, I'm +1 for the drag select/double click 3d cursor proposal,
-Sean Olson (LiquidApe)


More information about the Bf-committers mailing list