[Bf-funboard] New Keymap: selection

[Nathan Vegdahl]

I'm working on the new keymap again after a bit of a break (yay!).

I'm currently working on the Mesh Edit Mode keymap, and I'd like to
bounce some ideas and query some feedback from the people here,
_especially_ people that do a lot of modeling.

----
1. Special selection tool importance:
Mesh edit mode has several special selection tools that don't exist in
other modes: loop select, ring select, and shortest-path select.  Do
you use all of these a lot, or are there ones that are more important
than others, that you use a lot more frequently?  Which one do you use
the most?  And what about other selection tools that are less
edit-mode specific, such as box and paint select?

The reason I'm asking is because it doesn't seem feasible to cram all
of these tools into the modifier keys.  And that brings us to the next
question:

----
2. For the selection tools that don't fit into the modifier keys, how
do we want them to work?  Should we go the same route as box select
and paint select, and have them be modal?  Or should we use regular
keys on the keyboard as modifier keys?  Or perhaps there are other
solutions I'm not thinking of...?

----
3. What modeling tools do you consider most primary for the kinds of
modeling you usually do?  What tools are important to be a single
key-stroke away, as opposed to (for example) being behind a menu, or a
multi-key combo?  I'm especially interested in hearing from people
that have really started modeling with bmesh already, since that
changes things.  Also account for tools that maybe aren't yet up to
par or (fully) implemented, but are planned and will be valuable when
they've gotten up to snuff (e.g. bevel).

Thanks!

--Nathan


On Wed, Apr 11, 2012 at 4:25 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> 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