[Bf-funboard] New Keymap: selection

[Jason van Gumster]

Resident old fart piping in ;)

Nathan Vegdahl <cessen at cessen.com> wrote:

> Okay, moved here from the development mailing list.  We're discussing
> a new keymap (or really, input map; includes the mouse) for Blender.
> I've started a wiki page here:
> http://wiki.blender.org/index.php/User:Cessen/New_Keymap

One thing I'd like to add in Principle #3 (Hand strain is bad), is that an
effort should be made to avoid press+hold interaction on keyboard keys and
mouse buttons. There are certainly some places where holding makes sense (e.g.
3D View navigation with the mouse), but press+release and (as mentioned
elsewhere) double press have much less strain on the hand.

> First topic is selection!
> 
> == Subtopic #1 ==
> I think it's high time we joined the rest of the world and switched
> Blender to use LMB for selection by default.

I still maintain that, for mouse interaction at least, RMB select is the way to
go. It seems to me that the primary beneficiary of LMB select are tablet users.
And it's already been established that there's no way we can effectively have
one keymap that's best in all instances. To that end, I'd like to suggest that
there be 3 primary keymaps to address various input concerns:

  - Keyboard + Mouse
  - Keyboard + Tablet
  - Laptop (assume no numeric keypad)

In the future, multitouch would probably be a strong candidate for its own
mapping as well.

Old-fogey-ism aside, there's one additional complication of the LMB select
model. That is, Blender's primary interaction paradigm is one of Select > Act >
Confirm. This is a good means of interaction and something Blender does really
well (much better, IMHO, than the typical Tool > Select > Act method in other
software) and I'd hate to see it lost. Current [general] behavior maps this as
RMB keyboard LMB. With LMB selection, are we also using LMB for the confirm
step as well?

> == Subtopic #2 ==
> The modifiers for selection are wildly inconsistent.  For example,
> when just doing normal click-to-select, no modifiers means replace
> selection, and the shift key acts as a combined extend/remove
> selection mode.  Whereas when doing box select, the default is to
> extend the selection, and then MMB is remove selection, and there is
> no replace selection mode.
> 
> I think this should be unified and made consistent.  There are 3
> things that a user wants to do when selecting:
> 1. Replace the current selection
> 2. Add to (extend) the current selection
> 3. Remove from the current selection
> 
> I propose that we standardize on "replace" being default, "add" being
> shift, and "remove" being ctrl.

I would suggest that it's likely more consistent to have "replace" as the
default, and map "add" and "remove" to Shift as a toggle. This is a more
expected behavior (a la Inkscape and other programs) and also requires the user
to remember fewer keys. I agree that the selection modes need to be wrangled
into consistency, but I think that the Shift-toggle behavior for add/remove is
worth keeping (and something that Blender actually already keeps in common
with other software).

Take care.

  Jason