[Bf-funboard] FW: Blender new keymap progress

[Nathan Vegdahl]

> > Good point.  I'll figure out a way to put that in.  I'm thinking that
> > RMB-drag would be good for that.
>
>
> please don't do this to such an integral use heavy tool (for me at least)
> The nature of tweak+drag is that if it's your main modeling tool (without
> resorting to G all the time) you tend to use it A LOT.

I must be misunderstanding something.  Isn't RMB-drag already the
tweak tool in the current Blender keymap?  So if it works for you now
in the current keymap, why not in the new keymap?

> Besides that ,unless you plan to change the shorcut for placing the
> cursor (RMB) then EACH time you tweak+drag you replace the
> cursor. Hardly ideal for visual an practical purposes.

I may indeed change the key/mouse combo for placing the 3d cursor, but
that's not necessary.  RMB-drag doesn't trigger RMB-click, so tweaking
would not move the 3d cursor.

> Again you assume that everyone works as you do. It is better to enable
> different ways of working. I did not know about space+number though,
> I'll try that out first.

My apologies if I have been presumptuous.  But on this point
particularly I was speaking from experience doing very
mode-switching-heavy tasks in Blender.  Believe me, I think mode
switching needs to be efficient.

Space-># is the same number of key strokes as ctrl-tab, and the hand
position is even more ergonomic.  If ctrl-tab is acceptable for mode
switching, then space-># ought to be as well.  Admittedly, though, the
fact that you can hit a number to choose a menu item is not very
discoverable right now, which should be addressed.  But that's outside
the scope of this keymap project.

[Regarding viewport shading: ]
> Another way is a 'button'+ # ,perhaps? If you do plan on promoting
> the space+ number (and along with vertex choices) making more
> use of that paradigm might make sense.

That's a very good idea.  The other advantage to that is that such
keys can be promoted to (optional) pie menus as well, if/when we get
those. :-)

The trick is that if we do that for a frequently used function such as
changing viewport shading, the key should probably be near the thumb.
So perhaps V would indeed be a good choice for that.  We'll need to
experiment.

> well mnemonics aren't really a big need anymore ,if you're ditching
> G,S and R (amongst others...) It's nice to have when most of them
> work like that ,but if only a few do,it doesn't matter so much anymore.

I'm actually trying to use mnemonics whenever I reasonably can.  My
rationale for ditching gsr is that translate, rotate, and scale are so
basic that they're on the level of basic selection and viewport
navigation.  The purpose of mnemonics is to make it easier to remember
hotkeys, but translate/rotate/scale are so basic and used so
frequently throughout all of Blender that even new users are
essentially forced to commit them to muscle-memory early on (just like
basic selection and viewport navigation).  So it seemed best to place
them as ergonomically as possible instead of worrying about mnemonics.

But for other things, I plan to stick to mnemonics whenever reasonable
and possible.  Essentially, I'm doing my best to balance ergonomics
and speed-of-use with learnability and logical layout.  We're not
going to get 100% of either, but 80% of both is better than 100% of
one and 0% of the other.

> As long as Tools and properties get some logical button placement
> I don't really mind.

I was considering [ and ].  Or maybe ; and '.  And really, any two
symbol keys next to each other.  Then they can be used for side panels
throughout all of the editors.  (N doesn't make sense in the first
place, and T only makes sense in some of the editors.)

> thanks for reading and considering some of my ideas.

Thank you for providing them!  Of course, I can't please everyone with
everything, but getting feedback from people with different workflows
and preferences is really important to making this keymap good.

--Nathan


On Wed, Nov 21, 2012 at 11:55 AM, Bol Bib <bollebib at hotmail.com> wrote:
>
>
>
>
>
>
> > > where is tweak+drag?
> > > Just selecting and dragging points without needing to to press a
> > > shortcut to grab is a must. I use it 85% of the time,really.
> >
> > Good point.  I'll figure out a way to put that in.  I'm thinking that
> > RMB-drag would be good for that.
>
>
> please don't do this to such an integral use heavy tool (for me at least)
> The nature of tweak+drag is that if it's your main modeling tool (without resorting to G all the time) you tend to use it A LOT.
>
> Besides that ,unless you plan to change the shorcut for placing the cursor (RMB) then EACH time you tweak+drag you replace the cursor. Hardly ideal for visual an practical purposes.
>
> I can get used to a lot but as a left button user I cannot see that being a plus.
>
> > I appreciate the idea, but I think it would not work out well in
> > practice.  Many people alternate rapidly between several selection
> > tools in their workflow, and having to switch via a menu (even one
> > brought up by a hotkey) is too slow for such things, I think, and
> > forces them to keep in their head what selection mode they have
> > active.
>
> the problem is also trying to guess what other people use most ofcourse.
> In my opinion the proposed idea could work if treated properly and would be preferable to removing options to select. But I'm not gung ho about it. Just that the current choices leave some things out.
>
> I don't care for box or circle select much but I wouldn't want to deprive anyone from having it.
>
> I guess I can always change LMB+drag to tweak select (if it's available),so it's not that bad ofc. But leaving stuff out is hardly ideal.
>
>
>
> and circle tool is bad just because it's modal (imo). I would prefer it as a selection tool that when it's active (just as an example: alt-lmb-drag) you can just resize it on the fly (with mousewheel) When using circle selection you can't do anything else which makes it annoying. If that would change it would improve as a tool.
>
>
> > I understand that mode switching is a little slower with the new
> > keymap.  However, mode switching is not done so frequently that this
> > is a significant slow-down to workflow (and I say this as a rigger,
> > which may well be among the most mode-switching-heavy tasks in
> > Blender).
>
>
> Again you assume that everyone works as you do. It is better to enable different ways of working. I did not know about space+number though,I'll try that out first.
>
>
> > Hmm... I'll have to think about this.  This is another one of those
> > cases where a toggle approach just may not make sense anymore.  You
> > may never use wireframe, but wireframe and solid are nearly the only
> > shading modes I ever use (aside from render with Cycles).  My strong
> > suspicion is that a lot of people will have their own "most commonly
> > used" shading modes, depending on the sorts of tasks they do.  So
> > there may be no good way to handle this with toggle shortcuts.
>
> that's why I propose having it on a button only for the viewport, this opens up 4 ways to change it,at least. I am glad you are willing to consider it. Doesn't really need to be v,as long ast it's not z anymore and has it's own button.
>
> Another way is a 'button'+ # ,perhaps? If you do plan on promoting the space+ number (and along with vertex choices) making more use of that paradigm might make sense.
>
>
>
> > Excellent point.  However, U could also be a good candidate (U for
> > "undo").  But it is good to keep related things on single hotkeys, so
> > perhaps z would indeed be better.
>
> well mnemonics aren't really a big need anymore ,if you're ditching G,S and R (amongst others...) It's nice to have when most of them work like that ,but if only a few do,it doesn't matter so much anymore.
>
>
> > > loopcut can still be CTRL+R
> >
> > I don't think that's a good idea.  Loop cut is a really primary
> > modeling tool at this point, and it needs to be on a non-modifier
> > hotkey.  Besides which, ctrl-r is a bit awkward to reach one-handed in
> > my experience, and could cause hand-strain in the long-term.
>
> I don't think it was akward,but I'm not about to impose my experience on someone else's ^^
> So sure. As long as Tools and properties get some logical button placement I don't really mind.
>
>
>
>
> thanks for reading and considering some of my ideas.
>
>
>
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard