Same problem here, esc key does not work to abort heavy operations in Rhino 5 for mac.
In my case the problem happens on “Make2d” operations on heavy scenes (threaded pipes and similar stuff) that, since they take forever to complete, sometimes i need to abort the operation and rethink the export in a smarter way.
Happened on any kind of files, so I think it’s no related to a specific file.
It’s very annoying, thanks to the autosave i’ve never lost anything, but having to force quit the application, still very annoying.
ESC key has never quit any kind of heavy command 
I think checked for Escape were added to Make2D for V7.
Have your tried the same operation in the V7 WIP?
Can’t obtain V7 wip since I don’t have a V6 license.
I’m using V.5.5.5, and in the bottom left corner I can see “Press Esc to cancel”.
But, as I said in the previous post, it doesn’t work, and having to force quit the application it’s not the ideal way to work.
Here’s a screenshot
Hi - at this point in the development cycle, we are no longer updating versions of Rhino 5 and are only fixing very specific issues with Rhino 6. Generally, all improvements and fixes are only introduced in Rhino 7.
-wim
Clear but, for what it matters, I think this is not quite fair.
I paid for a software with an advertised function that does not work (even if the software says that it does “press esc to cancel”).
Now, since I’m using macs that are not compatible with OS newer than OSX 10.11.6 El Capitan, I can’t upgrade to Rhino 6 (which can’t be installed on El Capitan).
For my workflow these macs are still more than ok thus I’m not planning to change them anytime soon.
That being said, it would be nice for a good software house (like i think McNeel is), not to leave users hung up to dry when it decides to drop back compatibility of their new software.
I always thought this was a bad habit from big software company like Autodesk, focused more on releasing a new version every year than giving a real updated software.
Since this issues forces me to “force quit” the application, it costs me time that equals money, and maybe I will be required to look somewere else.
You can check my subscription date to the Rhino for Mac development program It goes back in the days to the very early releases (and I started with Win Rhino 2.0 for the Product Design Firm i used to work for in the early 2000’s), and I always appreciated Rhino for its flexibility and the capability of handling a very large amount of file formats.
Sorry for the long moan, but this approach makes me very sad and I think it was right to express my thought.
Hi -
That’s fine. No problem with that.
-wim
You can’t expect software companies to fix bugs in very old versions of software (nobody does). And you also need to expect that from time to time you will need to upgrade your machine if you wish to take advantage of the latest versions and features of operating systems and software. Rhino 5 is 5 years old - eight, actually if you count the Windows Rhino version it is based on - and will soon be 2 versions behind as V7 is already in the late stages of development.
You know this is not true for McNeel - i.e. 4 years between Rhino 5 and 6 for Mac.
I agree that there must be some sort of time limit on bug fixes for different versions of software but people were complaining about the failure of Esc to abort for a long time when version 5 was state of art and this bug has certainly cost me in time and money, too. So, I concur with tnt_!
The developers prioritize their work based on how many people are touched by the bug, how egregious it is, how complicated the fix it (don’t want to swap one problem for others), etc.
Time is a consideration but we do not drive development based on the calendar.
In the early days of DOS, ctl-c was needed almost on a daily basis to get out of infinite loops and hung programs. I don’t think the importance of being able to break a hung operation without program restart has diminished; indeed it has probably increased, albeit with lesser frequency as software has become more reliable. I take your points about how developers priotize but I am surprised that this one didn’t get more elevation. The big time loss comes from not knowing if the program has hit a bug or is just taking long time to complete the operation. So, one waits and waits, hoping that it is the latter, only to finally give up and force quit Rhino. I am further surprised that more users didn’t flag the issue because I have been caught out by this many times.
1 Like