[Bf-funboard] New Keymap: selection

[Jonathan Williamson]

1. Special Selection Tool Importance
I would put loop and ring select as the most important, in that order. I very seldom use shortest path but it's useful from time to time. I also use Lasso and Box select the most, occasionally Circle select. 

2. Selection Tools outside of Modifier keys
Personally I like the behavior of the Lasso select with merely CTRL + LMB drag. I would like to see box select work like it's expected in nearly every other software with just LMB+Drag. Then perhaps keep the current behavior for lasso select.

3. Modeling Tools
Having used BMesh extensively now, and aside from the normal grab, rotate and translate, I would rank tools in this order:
Extrude
Inset
Bevel
Knife tool
Vertex connect
Make face
Subdivide
Duplicate

The top six are all pretty close contenders. 



-- 
Jonathan Williamson
Education Manager and Instructor 
CG Cookie, Inc
http://cgcookie.com


On Thursday, May 10, 2012 at 8:15 PM, Nathan Vegdahl wrote:

> 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 (mailto: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 (mailto:jason at handturkeystudios.com)> wrote:
> > > Resident old fart piping in ;)
> > > 
> > > Nathan Vegdahl <cessen at cessen.com (mailto: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 (mailto:Bf-funboard at blender.org)
> > > http://lists.blender.org/mailman/listinfo/bf-funboard
> > > 
> > 
> > 
> 
> 
>