(wish / bug) Pure keyboard Input

Rhino
,
1

sorry but i have to emphasis on this:
I strongly wish that there is mouse position independent, pure / Keyboard only input.
Teaching a beginner class today i - again - came across 2 aspects:

  • extrudeCrv : direction depends on Mouse current mouse position. see this old topic. my strong wish:
    type 10 as extrusion height, press enter = pure keyboard input, direction defined by c-plane or by CCW Curve Direction
    type 10, click on the viewport = numeric input combined with mouse clicked direction
    Students with other CAD background (Solidworks, Inventor, … ) always struggle and not all commands behave the same. For example _extrudeCrvTapered.
  • (bad) “dominant smarttrack” currently smarttrack is strangely dominant over Keyboard input: (select object) _rotate (“…center…”) pick point (… you ll get some smart track from the center) move the mouse to a perpendicular smart track position. now (prompt: angle or first reference point) 90 enter (90 is ignored), the enter will be taken as first reference point. i would call it a bug. Mac version will accept a second enter and keep the 90, windows version will loose the 90 as input.

pure keyboard input is also important for macros to function repeatable. A macro depending on mouse position is a huge pitfall.

Regarding consistency:
clicking with the mouse in the viewport the user was using the mouse as a input, mouse position should matter.
input stuff by the numpad or Keyboard and pressing a key / pressing enter, mouse position should not matter.

any other mixed concept as we have currently does - in my eyes - not make sense. in comparison to the experience with other (CAD) Software and regarding the learning curve … if new users have to learn stuff like:
… for this command mouse position is influencing the direction / for this command it s not
… this numeric input will be ignored if some kind of smart track is active…
puuuh that s a hazel.

thanks for this important fine-tuning.

kind regards - tom

2

This was discussed at length in Gives me swish
So by the looks of it changing it to the way you suggest might make a lot of people unhappy.

3

yep but the old topic was not 100 people saying "forget about +/-, just look at the mouse.
and in the old topic also very critical voice raise exactly the same question as I do here.

And it was never discussed - my compromise / suggestion:
finish with a mouse click = direction by mouse
entering numeric value + finish with pressing enter = direction by +/-

and from a general ui-design aspect - the concept of typing something on the keyboard, pressing enter and the mouse position matters - even when the mouse position left the viewport.
sorry but this is not a coherent concept.

and if this concept (direction by mouse only) would be superior, it should be implemented for all commands like _extrudCrvTapered _box (3Point) … and many more.

if you want to see if the concept is intuitive - look at newbies - and when ever i try to explain them how the direction is set - they somehow struggle.

do you want me to continue the 10 year old topic ?
why shouldn t we say we need to fine tune a decision we made a few years ago ?

4

I am not disagreeing with you, we certainly need to go for consistency at the least.
I’ll give this some more thought tomorrow and come back to it.

6

@Tom_P as mentioned, first thing we need to do is make sure these commands work the same:

ExtrudeCrv
ExtrudeSrf
ExtrudeCrvTapered
ExtrudeSrfTapered
ExtrudeSubD
ExtrudeMesh

Currently the first two behave differently from the the rest.
What I have in mind is that this could be done with a global toggle (that is accessible from within the command), something like UseCursorPosition=yes/no
With global I mean: setting it for one command sets it for all, and the setting persists application wide. Thoughts?

7

Dear @Gijs
thanks for your effort.

global setting

i think a global setting is a conservative backup to address this.
As a creative person i love to collect ideas and i really hope we find something better then one more setting that everybody customize… (similar discussion with dominant ortho…) would be nice we find a single rhinocerosly approach…

direction / distance - gizmo

there are more commands that want cplane / direction / +/- or related input:
offsetSrf (flip-option)
offset (Curve) (which side), mirror (which plane), revolve (which axis - press enter to use current c-plane z direction),
blendSrf (planar Sections),
also _revolve interacts CW/CCW by mouse movement !!!
…(and for sure many more)

I totally see that there are users that wish to have a pure mouse input
…- and others want pure keyboard input.
So lets come up which a nicer, explicit, visual input method:

so why not introduce a gizmo / single-Arrow-like-Gumball-Widget ? grayed out, mouse / over or clicking will color it up (blueish as z-like), clicking (or double-click?) on it will reverse the direction (like we have for dir, loft / align / set curve direction), dragging will interactively set the direction (snappy-gumball-style ;-D)

what is really nice about the gizmo - it can offer more then one direction (current-Cplane-Direction vs curve-plane) or can be viewport-specific

and it will perfectly match with gumballs extrude feature. (<- this is a huge win i think)

so this will end up with keyboard vs mouse:
→ ignore the grayed out gizmo / do not click / do not move the mouse → input via commandline only.
→ interact with the gizmo → mouse action / direction by mouse
Important: leave the viewport, click in the commandline = keyboard input
(actual it would be great if you click he gizmo to change direction, that the commandline input changes +/- so both approaches stay synchronized)

finish enter-key or mouse-click

(actual i like the gizmo idea more - my old, initial suggestion:)
→ finish the command with a mouse-click in the viewport (after moving !!) the mouse → direction by mouse
→ finish the command with enter → numeric keyboard only.

→ moving the mouse … snapping points… = mouse only input
→ type a value (creates a purely numeric preview)
… → press enter = done
… → move the mouse = direction might change, commandline sign updates +/-

test scenario / edge cases

… commandline - mouse-move-Synchronisation
i think the ugly (test) scenarios are
… if a user wants to start with a pure mouse input, gets some visual feedback and changes to do do keyboard input
… or reverse: the user starts with numeric / keyboard input but wants to use the mouse to define the sign / direction.

this is - why i think if the mouse changes the direction, the numeric input needs an update.
(15 will become -15 if i move the mouse)

other cad

many other cad use a gizmo-like approach or have a “change direction arrow / icon” to click on. (instead of +/-) input. It would be nice to do a research and not reinvent the wheel…

the old topic

… i went through it … the idea of a preference was there as well.
@Gijs feel free to merge this topic with the old one Gives me swish or maybe better / it s a nice idea to invite “@” some of the people (arround 12-15?) from the old topic …
what is quite amazing: you can print-copy the old thread / topic and let chat gpt do a nice summary / table of different opinions… the decision / voices to have mouse-related input only had a very weak majority, the critical power-user have a lot of arguments …

… looking forward to see some discussion and hopefully improvements in this field.
(still would love to see a better _matchSrf first ;-D)

cheers - tom