[Bf-funboard] New Keymap: selection

Thu Apr 12 08:31:36 CEST 2012

I just wanted to add that any key combination that makes you take you hand
from the board makes it so you have to look at you hand and that cost way
more time than you might think plus it makes working in the dark hard
especially with older eyes. I know when I was young I never thought about
this but old eyes take have bad night vision and also take much longer to
refocus. You know how old guys get accused of staring at young woman more
than young? That is because they have to wait for their eyes to focus and
they of course get caught at it (plus they don't care much about getting
caught, LOL). Anyway it should be left hand on home row right on mouse, no
lifting of the hand  needed.

On Thu, Apr 12, 2012 at 1:25 AM, 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
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard
>

-- 
Douglas E Knapp

Creative Commons Film Group, Helping people make open source movies
with open source software!
http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php

Massage in Gelsenkirchen-Buer:
http://douglas.bespin.org/tcm/ztab1.htm
Please link to me and trade links with me!

Open Source Sci-Fi mmoRPG Game project.
http://sf-journey-creations.wikispot.org/Front_Page
http://code.google.com/p/perspectiveproject/