i found a closed bugtracker from that seemingly in Rhino 6 fixed issue, but in Rhino 7 it again does not work. i cant remember if it ever worked, i had not much time with version 6.
hi @pascal @dan is this a regression or do you know what happened here?
@tim ?
using the mouse to hover over to apply keeps making knots into my cord … 
Hello - I do not know if this can work - Enter accepts the numbers in the current field - would you want to ‘apply’ on a second Enter?
-Pascal
i would like enter to finish the command completely. hovering back up to that little box to complete box edit is not very helpful, specifically since one now can throw in the numbers and tab further to complete all numbers. hitting enter does actually nothing additionally since the changes of any value are reflected immediately.
honestly i think the button apply should be made obsolete entirely, so that changes are completed after entering new values.
@pascal what is the outcome, did i misunderstand the bugtracker, and/or shall i mark this as a wish?
Hello -what does finish mean in the case of a panel? The panel does not go away, it hangs around for you to fuss with the next selection. If you typed a number for a scale you’d presumably Enter at that point - what should happen, ‘Apply’ each time? The object would be replaced in the document and only Undo would get it back to how it was… Is that OK?
-Pascal
yes of course not, i dont mean the panel to go away, but to keep the given changes. right now i can hammer as many enter as i want after changing the values but once i click into the viewport the changes revert back to where i came from. the magic button apply which i outlined green in the screenshot above is unfortunately the only way to keep the changes… or am i missing a secret way to confirm/apply the changes?
i am puzzled how that can be so complicated, did you have a look at the mac version? maybe there is some general confusion going on? is it a bug is it a regression is it a misunderstanding, i have not clue
but it does not work well in its current state.
no i dont want to even hit enter, i use tab for each change till i hit enter which would simply complete box edit.
Pascal added this to our bugtracker and I’ll try to take a look at it soon
Hi @encephalon, This is how the Windows version is currently working: tab, tab, tab, then when you are ready, a single Enter to apply the changes. Is the Mac version different?
You are correct- it is different and less handy on Mac. Thanks for persevering.
-Pascal
thanks Steve! Also what would you think if enter would generally be made completely obsolete? meaning no confirm needed. entering the new values should do. it might be just one button less but it could improve the workflow.
I would be hesitant to make a change like that in V7. This would cause an awful lot of objects to be created and replaced as you step through different inputs. My guess is this would dramatically slow things back down to the time when users were complaining about performance…
I don’t think you save a button. After typing in a field you will have to indicate that you have finished entry for that field (otherwise how does Rhino know?). Lets say tabbing out is an indicator. As things stand (in Windows anyway) you don’t need to tab out of the last box you want to change because you can hit Enter. If you couldn’t do that you would have to tab out, so same number of keys.
If tabbing out causes an update to the drawing (and if you don’t have the final enter then it must do because Rhino can’t tell from that tab if there is another change to come) then every box you change is queueing up another drawing change. If you are working on large, complex or heavily multiple geometry, that is going to slow things down. Enter has the advantage that you can choose to combine all the transformations and apply them in one hit.
Jeremy
p.s. Although voice response would be good, “Add ten to X, wait for it, Y minus 3, wait for it, rotate around z by radian over two, wait for it, move 10 in the z direction, go Rhino!”
yes sure, not V7 but an idea for future versions. i did not understood why it would replace objects and slow down performance different to confirming with enter?
currently at least in Rhino for Mac and here i also reply to @jeremy5 → when i select a bunch of squares for instance and use BoxEdit the changes show up in real time after entering a number see video below.
that means the objects are already being created/changed and could just be left as such without having to confirm the change additionally.
Previews of existing transformed objects are being shown until the apply action is taken. This is not the same as creating new objects for the document.
not sure i can follow, but i am brave and state a question followed by some babbles. so the data of the transformation is held in the GPU only till it gets confirmed? But why would it cause so much havoc if created right away? sorry if i keep bothering just curious. Also keep in mind that with the dawn of Apple SOC, GPU and CPU Memory is basically the same which is an imminent change also facing the pc users at some point not far into the future, at least if we consider a similar technology.
Geometry exists in the document and is lightweight to preview with transformations applied. When geometry gets added/deleted from the document all sorts of actions are taken including adding the old geometry to undo records, calling event watchers that panels and plugins pay attention to and potentially perform long running processes.
but all that will happen anyway when the user decides to hit enter? i am not sure i am misunderstanding something.
That will happen when you hit enter; not while you are fidgeting between different values in different input boxes.
ah… i think i got you, that means when i start a number 3 then add 0 and maybe another 0 three different geometry changes would be applied. is that the problem?
