10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default

Feb 23, '12 07:30:00AM

Contributed by: Anonymous

Lion seems to have broken the ability (or at least made it tremendously unreliable) to have Command+Tab only apply to the local machine when controlling another host via screen sharing. This hint offers a possible workaround.

Prior to Lion, in most OS X versions where screen sharing was supported natively (Leopard and later, I think), Command+Tab switching through apps on a machine controlling another host via screen sharing would only switch among running apps on the local machine. [crarko adds: That's actually not been my experience, hence the defaults setting mentioned below.]

This behavior has never been consistent however, and somewhere along the line, a default was introduced:

defaults write com.apple.ScreenSharing DoNotSendSystemKeys -bool TRUE

This allowed some user choice in the matter. This seems to have stopped working in Lion, but I have also noticed that sometimes the system spontaneously reverts to restricting Command+Tab to the local machine anyway, but often after a reboot, it's back to the behavior of Command+Tab going to the apps on the remote machine, with no (keyboard-only) way to get back out.

Quite by accident while this was happening, I happened to be looking at Activity Monitor, and noticed a process I hadn't seen before: RFBEventHelperd, owned by _ard (the screen sharing system user). On a whim, I tried killing it (it didn't hurt anything), and at once, my Command+Tabbing is happily only affecting my local machine again.

Note that you may need to enter the above defaults setting in Terminal for this to work. I haven't tried without it being set.

[crarko adds: I tested this, and it works as described. I also didn't notice any bad side effects from killing RFBEventHelperd, but if anyone does, please post them in the comments.]

Comments (5)


Mac OS X Hints
http://hints.macworld.com/article.php?story=20120221065822722