[Bf-funboard] New Keymap: selection

[Nathan Vegdahl]

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

That's a very good point.  Though from my XSI days, I must say I do
think holding down letter keys to affect behavior (e.g. like holding
down d for grease pencil) can be really nice.  And XSI's sticky-key
concept is a nice compromise: holding down a key puts you in that
mode/tool only as long as you have it held down, but
pressing+releasing in a short time (e.g. clicking) the key toggled you
into the mode/tool.  That way, for example, if you just need grease
pencil for a moment, you would hold down d, draw something, and
release d; but if you were going to do more substantial drawing, you
could click d, do your drawing, and click d again when you were done.
I'm not sure if we actually want to do that in Blender, but it's
something to consider.

> It seems to me that the primary beneficiary of LMB
> select are tablet users.

As a tablet user who strongly prefers RMB select (tapping to select
feels really weird, IMO), I disagree.

The primary beneficiaries of LMB select are people who use any other
software (including their OS).  LMB-select is one of the most
ubiquitous UI standards in modern software design.

I understand the select/action distinction for RMB/LMB.  And it does
have benefits.  But I think they are not large enough to justify
holding onto this.  Besides which, Blender already fails to be
consistent about it anyway.  Text editor, outliner, any time you're
editing a field... they're all LMB select.  We should at least unify
which mouse button is select within Blender itself.

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

Agreed.  But I don't think this is relevant to whether RMB is select
or not.  We can still keep that model with LMB select.  In fact, the
only parts of Blender that seem to conflict with LMB select right now
are the parts that explicitly _break_ that model (e.g. painting modes,
which are very Tool > Select > Act).

> With LMB selection, are we also using LMB for the confirm
> step as well?

Presumably, yes.  And Blender will likely become more LMB heavy
because of this.  But that also means it frees us up to use RMB for
other things.

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

Agreed that "replace" should be default.

I disagree that shift should act as "toggle selection".  For two reasons:

1. Blender's concept of an "active" item means that in most cases if
you want to unselect something, you have to shift-click it twice.
This is annoying, and can also sometimes go wrong when there's more
than one thing under your cursor (e.g. Blender will first make what
you want active, and then select something behind it that was
unselected).  This has honestly been an annoyance of mine for years.

2. Box select / Lasso select / Paint select / any future multi-select
tools we may add.  With tools that select multiple items, "toggle"
becomes "invert", which, while cool, isn't nearly as useful as add and
remove.  For these multi-select tools, we need separate ways to
indicate add and remove.

--Nathan


On Wed, Apr 11, 2012 at 2:59 PM, Jason van Gumster
<jason at handturkeystudios.com> wrote:
> 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
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard