There is this new bug in the Gumball Numeric entry function.
When you click one of the arrows it takes a few milliseconds for the input box to open.
But this really drives me nuts. I use this field all the time and I really don’t want to wait a full second before typing in my values.
I don’t know if you can see it, but when i click the arrow it has some delay before opening the field.
So to sum up:
The problem is: Latency between clicking the arrow and the field popping up.(you can test this out yourself)
Solution would be: To remove this latancy / Make it even less, so the behaviour is more like rhino 7.
Hopefully you can fix this issue in the next update.
there is a delay because we added a double click function to the gumball to relocate it. That being said, there is no delay for typing. You should be able to type right after clicking, and you will notice in that case the box will show faster.
i was probably first to point this out. it is due to double click. i strongly suggest there must be an option to change double click for right click which would return no delay numeric input. for workflows i use and apparently more users that delay is a no go. this is a huge thing nothing that can be ommitted or ignored.
We discussed this already elsewhere.
In Rhino 7 you could CTRL-click to relocate gumball accurately. Translation, rotation and scale.
You digit a positive/negative number and when you press enter it do the thing. Simple, fast, obvious.
In Rhino 8 double-click, after entering the number + enter, it will result in the Gumball UI “hanging” there waiting for an additional click… making the sign of your number useless. Slower, FAR less intuitive.
Scale handles behave worse, now the number is used as absolute length instead of factor… no idea if this can be considered an actual improvement. I’d say it should behave the same as the single click, at least.
Once again, why change the CTRL-click for the gumball?
“Don’t touch what is not broken…”
Did someone at McNeel kept track of all these ““small”” (but potentially big) changes like this one?
It would be useful to even just read about all the changes, instead discovering them months later when you guys will no longer even remotely consider re-changing them.
Remember that users have a different experience and opinion that you devs…
Tnx for the reply. I agree that there is no delay in typing but there is a delay in confirming the number.
If the value you need is already there you would just left click, open input field, and immediately right click confirming the value. This is now a broken mechanic, right clicking to soon will make it behave like a repeat last command input.
Here you see that my repeat last command was _Zoom _Selected. You clearly see that right clicking to soon will repeat that command instead of just confirming the value.
Personally I never freely move the gumball around. (only with _GumballAlignment).
I hope that there is still an option to fix this and maybe change the double clicking machinic.
I see, yes in that case you will have to wait indeed. Only when the gumball move was the latest action there is no wait required.
I’ve logged this as: RH-79440 Gumball click on handle repeats last command
Echoing others’ comments here re: preference for Ctrl+Click to relocate Gumball.
Feels more explicit, efficient, fluid. Also more consistent with the rest of the Gumball functions IMO. And in any case, the inability to click a gumball handle and /immediately/ hit enter to repeat the stored transformation is the single biggest bug/drawback of R8 currently, and the only thing preventing me from fully switching over.
I’ve been running into this exact issue regularly in R8, finally realized what was happening and found this thread. I just downloaded 8.4.24023.15001 and it seems that the issue has been somewhat tackled but it’s still not perfect.
The behaviour is now quite inconsisent (or maybe I’m crazy and it did the same thing before too?). If I use Spacebar or right mouse click, it now does different things depending on how small the delay is. If I’m really fast (which I’m almost always TBH), it’s broken like before and last command is repeated. If I’m slow but even still slightly faster than the entry field appears, then it works as expected and gumball action is activated. But there’s also this hybrid state if the delay is between these too when it moves the object via the gumball action but it ALSO repeats last command.
Weirdly enough, if I click gumball arrow and immediately press Enter or Num Enter key, then now matter how small the delay is, it always works perfectly! The only problem is I never use Enter when repeating last numeric entry as it’s the least conventient way if I’m not typing numbers on the num pad and instead have my right hand on my mouse.
Is it possible that it’s only been fixed for Enter key but you forgot to also fix it for the two alternative ways to confirm action, that is spacebar and right click? Would it be easy to fix that too or is there some underlying reason why it behaves differently with these two?