Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default System 10.7
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.]
    •    
  • Currently 2.83 / 5
  You rated: 1 / 5 (6 votes cast)
 
[5,003 views]  

10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default | 5 comments | Create New Account
Click here to return to the '10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default
Authored by: NovaScotian on Feb 23, '12 08:25:12AM

I've found that this behavior depends on where the cursor is. If in the shared screen, the command goes through to the server, if outside, it applies to the local Mac client.



[ Reply to This | # ]
10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default
Authored by: msadesign on Feb 24, '12 05:21:21AM

and isn't this how one expects the thing to work?



[ Reply to This | # ]
10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default
Authored by: NovaScotian on Feb 24, '12 07:00:28AM

Exactly.



[ Reply to This | # ]
10.7: Make Lion honor the com.apple.ScreenSharing DoNotSendSystemKeys default
Authored by: dilvish1984 on Feb 25, '12 09:07:21AM

Do you mean to say that it depends on whether Screen Sharing is the active (frontmost) app on your local machine? I can't imagine that they would set it up to respond to which window the mouse pointer is over (and indeed that isn't how it works on my machine) since there are actually two mouse pointers whenever you move it outside the screen sharing window (one local and one remote) and that would become terribly confusing (and therefore un-Apple-like).

As for the original hint, I have to say this seems like a bad idea to me, and a bit extreme just to get around a minor annoyance. Setting the defaults value was fairly safe, since some programmer had to anticipate its existence, or it wouldn't be coded into the app in the first place. Randomly killing a spawned process that the app may be relying on for more than you think is not something that a programmer should be expected to anticipate or accommodate. At the very least, this hint should have a very prominent "Use at your own risk" warning...



[ Reply to This | # ]
An Applescript Solution
Authored by: Rainy Day on Dec 16, '12 01:38:30PM

I'd prefer that DoNotSendSystemKeys were still supported. Or, better than that, Apple should include a menu item and a toolbar shortcut/button option. But in the interim…

Here's what i've learned:
  • Killing the RFBEventHelperd daemon seems to work regardless of the DoNotSendSystemKeys setting.
  • This is a one-shot solution; need to redo it every time you invoke a screen sharing session (not surprising).
  • After you kill the initial RFBEventHelperd daemon, Screen Sharing will startup another one whenever it's moved to the foreground, however the second one doesn't interfere with command-tab, and it will quickly (but not immediately) die if Screen Sharing moves to the background.
I wrote an Applescript to make killing the RFBEventHelperd daemon more convenient. I've placed it in ~/Library/Scripts/Applications/"Screen Sharing"/ for easy access from the Scripts menulet. Save it as an Applescript Application:


try
	do shell script "$(ps -cxao pid,command | grep RFBEventHelperd | awk '{print \"kill \" $1}')"¬
	    with administrator privileges
	activate
	display dialog "This session of Screen Sharing should now ignore Command-Tab." & return ¬
	    & return & "You’ll need to rerun this script for the next Screen Sharing session."¬
	    with icon note buttons {"Okay"} default button 1
end try

I used the name "Kill shared Command-Tabs", but you may call it whatever you like.

Note: If you don't want to display the dialog at the end of script execution, you can reduce the Applescript to this:

do shell script "$(ps -cxao pid,command | grep RFBEventHelperd | awk '{print \"kill \" $1}')"¬
	    with administrator privileges

Theory of operation: The do shell script calls a bash (i.e. Unix) script which looks for the RFBEventHelperd process. The awk command extracts the process ID, and creates a Unix kill command, which is then executed as root (necessary in order to kill RFBEventHelperd, as it is owned by another user… i.e.: _ard).



[ Reply to This | # ]