New Gumball is devastatingly bad. Here are some proposals how to fix it

Since several weeks Gumball had some changes, some good and some really bad. These are the bad things that are destructive for the modeling, and here is my overview of them, along with some proposals how to fix the issues:

  1. The square handle whose original purpose was to enable to freely move the selection across two axes simultaneously is now doing the opposite while Ortho is active! Instead of providing a free movement, now it’s restricted by Ortho even though the dedicated axis arrows exist for this exact purpose. Working with a 3d connexion device while using the square handle of the Gumball is a nightmare when Ortho is active. Me and many other Rhino users have Ortho turned on all the time, because it will prevent accidental moving in a random direction. However, since the new changes of Gumball were introduced, I’m forced to leave my 3d mouse every time when I want to use the square handle of Gumball to hold the Shift key to move the selection freely. Or, I’m forced to constantly switch the Ortho on and off, which is also bad, because it requires many extra mouse clicks. Not to mention that sometimes I forget to turn Ortho on again and that further leads to unwanted movement of objects in a random direction. Currently, the square handle is useless, because it doubles as an arrow restricted into moving in either direction, instead of being free as before. This must be changed as soon as possible. Old Gumball was much better.

  2. Dragging a selection with an arrow now remembers the last distance, even if no numerical value was entered manually. This has its strengths and weaknesses. One weakness is that users don’t have an option whether Gumball would remember the last used distance either from (a) manual dragging or (b) numerical input (like it used to be until one month ago). Some Rhino users prefer the old way, some prefer the new way, but having an option to choose would be greatly appreciated.

  3. Even though remembering the last used distance for moving with an arrow is a nice feature, it will only repeat in the same direction as the previous move. However, sometimes it’s essential to have the option to move the selection in the reverse direction, so in this case a solution must be invented to allow moving along either direction (probably tapping the Tab key to flip the direction, because that key is anyway universally used to flip or lock directions; or by holding the Ctrl key while tapping the arrow). Currently, tapping the Tab key while the last remembered numerical value is being displayed simply acts as a confirmation to move the object, but in my opinion it would be more intuitive to flip the direction instead. The same applies to the rotation via Gumball.

  4. Double-tapping on an arrow with the LMB is extremely aggressive and that leads to unwanted movements, because Rhino will use the last distance to move the selection! I propose to increase the time interval required for Rhino to consider a double-tapping with the LMB, in order to prevent accidental movements. Double-tapping below 0-3-0,5 seconds must be considered a single tap to keep manual dragging safer. When I drag control points multiple time, I do it in quick intervals, but the new changes of Gumball sometimes ignore my small movements but consider these quick clicks of the LMB as double-tapping and use the last distance instead. It also evokes the tiny pop-up window to enter a numerical value for a moment, which I don’t want to see while dragging the arrow.

  5. Single-tapping on a Gumball arrow or arrow line brings the tiny pop-up window to enter a numerical value. This may be useful for some, but is extremely disruptive to others. Let me explain. When I manually drag with Gumball, sometimes it may bring the aforementioned pop-up window with the numerical value. When I click anywhere on a blank space in the viewport or even on the window bar, Rhino will NOT consider this as a canceling command to hide the pop-up window. Instead, Rhino moves the selection with the last used distance, which is extremely annoying, because that causes unwanted moving of an object and forces me to use Undo. This is really, really, really inconvenient.
    For example, when I click on an object, I select it. When I click on a blank space in the viewport, the object is being deselected. This is intuitive. However, when I click on an arrow and it brings the tiny numerical pop-up window, it’s very counter-intuitive to activate it upon clicking on a blank space or even on the window bar. Doing so should hide the pop-up window and keep the selection on the same place instead of moving it.
    Moving the selection via a numerical input when the tiny pop-up window is already shown should only happen when the arrow’s tip is being specifically clicked with the LMB. Any clicking on a blank space must NOT be considered a confirmation to move the object further. I

  6. There is no distinctive way to choose whether to bring the pop-up numerical window or not to bring it. No matter if I click on the arrow’s tip or the arrow’s body, Rhino always brings the pop-up window, then clicking on a blank space moves the object and forces the use of Undo, as I already mentioned above. I propose to bring the numerical pop-up window only if the arrow’s body is being clicked, while tapping the arrow’s tip will NOT bring it. However, double-tapping the arrow’s tip with the LMB should move the selection with the last remembered value, BUT only if the time interval for the double-taping is long enough (see subsection #4 above). That way, users will have a secure way to bring or not to bring the numerical pop-up window.

  7. There is no option to double-click on Gumball’s square handle to bring a numerical pop-up window to move the selection in the same random direction and distance as the previous move that was done via the square handle.

  8. Rhino will not remember different distance values for individual axis. For example, if I move an object by 3 mm along the Y-axis and then by 10 mm along the X-axis, a subsequent double-tapping on Gumball’s Y-axis arrow will move the object by 10 mm instead of the lastly used distance for this specific direction. Sometimes this could be good, sometimes not, so I think that there must be an option to choose which behaviour to choose from. Imagine you want to build something with shapes like bricks that have much wider size than their height. Being able to remember two different values to the individual axes would make the workflow so much better, because it will let the user move the object with different distances depending on the direction.

8 Likes

Personally I don’t like that the text field remembers the manual drag value. I can see where this is coming from. Maybe a shortcut could replace this feature. So instead of remebering an arbitray value, how about a shortcut that simply allows you to repeat the last action? Something like in Sketchup where you create an array very quickly by tapping x5 or whatever times you want to move something?

2 Likes

Remembering the last distance after a manual drag is useful, but I can also see why some people may prefer to have the manually written value remembered instead. Both of these are usable depending on the situation and the person. This is why I think that it should be an option so that everyone could choose which behaviour of the remembered value to use. :slight_smile:

Another thing to consider is that there is no storing of last used values for moving, rotating and scaling. Also, no stored values for diameter/radius while creating circles, arcs and adding fillets. Rhino only remembers the last used value for these, but there is no list that gives you at least 5 different last used values.

1 Like

You’re right :slight_smile:

I guess the best thing right now would be an option to choose from numerical input or drag value.

1 Like

I am not very familiar with advanced gumball techniques.
however, I totally agree below.

clicking in the void with the left button should suspend all operation with the gumball.
.only a right click must execute the displacement or the scaling.
this way we are sure not to commit unintentional mistakes.

(if I’m not talking nonsense) this is the rule for all commands in rhino !. why only gumball derails from this rule. it is an inconsistent thing.

2 Likes

Thanks for the feedback, y’all, I’ll let the develper know…

-Pascal

2 Likes

Thank you, Pascal, and thanks to all the Rhino developers for listening to the community! :grinning:

Cheers,

Bobi

This bit feels like a bug to me.
RH-65751 Gumball: remembered value is used too agressively

-Pascal

3 Likes

I agree: when the Gumball axis numerical input contains a number and blank space is clicked, this is taken as ‘enter’, not ‘cancel’. Quite irritating. It should be ‘cancel’.

2 Likes

RH-65751 is fixed in Rhino 7 Service Release 11 Release Candidate.

3 Likes

Cool. This should solve issue #5 in the original post above. :slight_smile: When do you think that issue #1 will be fixed, too?

@dan @pascal sorry for the tag and for bringing this up again
I would not press on this topic if it was not a big issue, at least for me

the first time I found the Gumball Planar handles were actualy not dragging the selected items on a plane anymore when Ortho is ON I honestly thought it was a bug, but I kind of understood that’s indeed a feature? :slight_smile:

the Gumball has arrow-handles if you want to drag things along an axis (regardless of Ortho: it will move the selection along the axis identified by the arrow you are clicking on)

and the Gumball has a plane-handle if you want to drag things on a plane, unless you have Ortho ON: in that case it will behave like if you are clicking on the arrow-handles :face_with_monocle:

in order to make both categories happy, either who wants the Gumball planar handles to operate following the Ortho setting as it’s currently doing, and who would like the planar handle to actually drag things on a plane regardless of Ortho settings, would it be possible/easy/feasible to implement something like this?
at least giving people a choice :slight_smile:

4 Likes

I totally agree. Honestly, my workflow is heavily worsened since the update that removed the ability of the planar handle to move in a free planar fashion across two axis simultaneously… I do a lot of object and control point movement with the handle and now I’m forced to turn off my Ortho setting multiple times a day, which causes occasional troubles with accidental movement in a random direction when I move something with the mouse pointer directly when I forget to turn on the Ortho again… It’s a really messy that way, because there is a huge inconsistency in the behaviour of the planar handle. Anyone who wants to move an object or control point along a fixed axis would simply use the axis arrows anyways… The planar handle was originally designed to allow simultaneous movement across two axis. It’s also that way in any major CAD program, but sadly the recent updates of Rhino destroyed that feature. :frowning:

2 Likes

Yeah I agree as well. The square should be unconstrained in any way… it’s about the only way to achieve that behaviour afaik

3 Likes

Thanks, y’all. I added your comments to the bug track item for the developer.

RH-65298 Gumball: Plane controls work with distance, angle, direction, and ortho constraints

-Pascal

5 Likes

Pascal, what I found in the link you posted above is referencing dragging an object with Gumball’s square handle while tapping the TAB key to lock the direction. That’s totally fine and usable. However, I don’t get it why it also mentions ortho constraints:woozy_face: The original topic that you referenced there was this one

and it was all about adding extra functionality for the Gumball and was never meant to suggest a limitation for Gumball such as the newly implemented Ortho limitation for the square handle that many people feel like a huge drawback. Hopefully this will be resolved soon.

some more proposals:

  1. make the circles for rotating continuous, instead of 1/4 of a sphere. it’s difficult to tell sometimes if the arcs are ‘innies’ or ‘outies’ and i find myself mistaking the axis i should choose to rotate a certain way.

I think every other software does this and it’s much easier to read:

  1. add options for filtering the gizmos for all/move/rotate/scale. this could be a selector you can click in the toolbar as well as keyboard toggle. again, every other 3d software does this.
2 Likes

In my opinion, Rhino’s Gumball is the better solution, because it combines all the handles simultaneously for moving, scaling and rotating. The majority of other 3d modeling programs usually have multiple versions of their gumball/gizmo, so they are unable to simultaneously show handles for moving, rotating and scaling. They would definitely look and feel overly-populated with all the handles at once while rendering full circle handles. This is the main reason for Rhino’s Gumball to have 1/4 of circle handles for rotation.

1 Like

Yes. I love the way the gumball works and looks personally. It ain’t broke don’t fix it (except minor adjustments re “square “ mentioned above)

i can’t easily tell in cases like this if the blue arc or the green arc is in the foreground.

image

I use the last dimension all the time to move stuff. I wish it was easy to move in the opposite direction without having to type and delete the minus sign… maybe if there was a dedicated move mode… with arrows on both sides.