There was a time when they were not integrated into the program, before Command Editor.
These were the Dark Ages of Rhino Mac… and yes, you could attempt to program them entirely through the native OSX Keyboard Shortcuts Pref Pane. It was terrible and not reliable.
Now, for the last year or two even they have been working well, Command Editor is exactly what it should be (Thank YOU!!!). Mac on par with Windows UI, even better in many ways.
Then, Boom. They break. Throw back Thursday.
Cmd+F2 will Lock Selected. But Cmd+Alt+F2 will not Unlock All. WTH!
How do I know this is a problem with RhinoWIP?
Because setting Cmd+Alt+F2 in the OSX Pref Pane Shortcuts WILL override RhinoWIPs problem and then the shortcut will run the command.
Also, because I’m running 5E12w on my iMac and Cmd+Alt+F2 works there, but not on my laptop. Both are running El Cap. I used the new (ImportPreferences / ExportPreferences).
It’s been obvious to me for years that there is something funny with the prioritization and handling of keyboard shortcuts. It doesn’t seem they are set up to reliably override OSX, and that makes the program much less usable, when switching between machines, we shouldn’t be expected to drastically change our technique.
More importantly, once a critical interface affordance has been canonized, (Keyboard shortcuts) they should be supported and made reliable, across platforms.
Please don’t explain this away as not critical since there are Icons… we all utilize and cope with 800+ commands in a different way, several ways in fact. Clicking on Icons for critical constant commands was never preferable for professionals.
I would like to ask for some additional information.
Clearly, you are reporting a problem with the RhinoWIP (5E12w). Do you have - or remember - a build/release when keyboard shortcuts worked as expected? As in: did they work in 5.0 but break in 5.1? Or…? You say: “Throw back Thursday,” so it sounds like this is something that just recently broke?
Cmd+F2 will Lock Selected. But Cmd+Alt+F2 will not Unlock All. WTH!
I just want to make sure I understand the reported bug. You have a custom shortcut that is commandF2 that is “Lock Selected.” I’m presuming that’s because you’ve changed the default (which I believe is “Maximize Front Viewport”). Is that correct?
Perhaps it would be easier if you ran ExportPreferences and attached the .plist so we could be looking at the same thing. Then we could compare notes regarding system shortcuts as well.
Yes, shortcuts have worked in the past.
If my memory serves, although it has been months… When 5 First was released, they worked but there was no Command Editor, and some could not be programmed.
Then another release would come out, and they would not.
Eventually Marlin recommended I switch to the RhinoWIP instead of commercial, and so they worked again.
Now an upgrade and they do not reliably work. There is no Rhyme or Reason.
Why would F2 : !_Lock work and Alt-F2 : !_Unlock not work? Why would Alt-F2 then work when programmed via Apple Prefs?
They are working right now on my other machine, my iMac with the same RhinoWIP. I performed an ExportPreferences from that working computer onto the laptop, on which the Keycuts are now not working fully. But again, OSX can override it, making them work, at least for Alt-F2.
Cmd+H is hopeless, as many know.
THAT is really what needs to be investigated, from my plebeian perspective.
Why should Apple’s Prefs technique override? Probably a similar reason it is blocking Rhino Mac from reliably working.
Thank your for the .plist and I apologize for the delayed reply. A couple of us looked at this here and I’m afraid we can’t figure out how to reproduce what you are seeing.
I presume you mean Command+H. This works perfectly for me with your preferences. I suspect you must have a macOS override somewhere.
Using your preferences files, I assigned the following:
Lock = F2
Unlock = ⌥+F2
Both of these work fine for me. Did you hold down the fn key on your keyboard when you pressed F2 to define the Keyboard shortcut?
-Dan
PS: We have made some changes to Keyboard shortcuts (since even 5E44w) that will make their way into the next RhinoWIP (coming soon). It might be worth waiting until this is published before testing again. Mainly, the changes relate to warning about duplicate shortcuts.
this, a fundamental shortcut, that come with the default list, and works fine
then what is actually the meaning of the comment that it is used by OS as well…?
I learned way too much about keyboard shortcuts in researching this.
It turns out there are two different ways to query macOS for the system defined keyboard shortcuts - one that returns too many system shortcuts, and the other that doesn’t return all of them. I was using the first list originally and am now using the second list. You won’t get false positive results any more, but you also won’t be warned about all possible conflicts.
There are some system-wide keyboard shortcuts that work only in certain conditions. These aren’t in the second macOS shortcut list and so won’t show up as conflicts in the Rhino Command Editor any more.
The Control-Command-D keyboard shortcut looks up the word under the cursor and displays the dictionary definition in a pop up window. But this only works if you are in a text field.
The Control-Command-Space keyboard shortcut is not documented anywhere, but you can find it in the Edit menu. It brings up the Emoji panel. It won’t be listed as a conflict any more.
I never could figure out what the Control-Command-S keyboard shortcut does (the shortcut that started this), but macOS would reliably report it as a system keyboard shortcut when using the original OS shortcut list. I’m sure it does something given the right conditions, but it also is not documented.
As of the latest RhinoWIP (5E75w), keyboard shortcuts defined by macOS should now be reported correctly. Please give it a try to make sure it works as expected.
