#9 multiple display patch

open
nobody
None
5
2006-05-05
2006-05-05
Leif Nelson
No

Brian Duff posted a fix on his blog for cotvnc which is described here:
http://blogs.oracle.com/duffblog/2006/03/19#a272

Here's the main description of the problem in his words:

I have a dual monitor setup at home: one 1600x1200 secondary display,
and the 1680x1050 display built into the Mac. In all, that's 3280
horizontal pixels spanning just under a meter, which is freaking sweet for
development :). Sadly, however, when you make the VNC window full
screen in the secondary display, CotVNC blacks out the primary display.

His patch was further enhanced by another person and the entre patch is
here: http://blogs.oracle.com/duffblog/2006/05/04#a317

I'm uploading a copy of the patched RFBConnection.m file which includes
both of these fixes.

This fix is what made cotvnc entirely useful for me, as I use multiple
displays, and was completely annoyed by this bug!

Thanks,
--Leif

Discussion

  • Leif Nelson

    Leif Nelson - 2006-05-05

    RFBConnection.m patched

     
  • Jason Harris

    Jason Harris - 2007-03-15

    Logged In: YES
    user_id=351330
    Originator: NO

    My only reserve on this patch is that capturing all displays causes Chicken to receive key commands like cmd-opt-d, which shows/hides the Dock, and thus allows these commands to be sent to the VNC server. The last time I checked (which was about two years ago), capturing only a single display broke this functionality. I don't want to break this ability, since I use it all the time.

    Maybe we should check to see how many displays are attached. If there's only one, use the existing kCGDirectMainDisplay method. If there are multiple, check a pref to see what to do. We should NOT expose this pref in the UI, though, it's too geeky for the average user. We should put it in the help file.

     
  • Jared McIntyre

    Jared McIntyre - 2007-03-16

    Logged In: YES
    user_id=751989
    Originator: NO

    It seems to me that the multiple monitor issues is a pretty big deal. I know several developers who have wanted this for some time. Do we know why cmd-opt-d, etc are now being caught? Is it supposed to be that way?

     
  • Jason Harris

    Jason Harris - 2007-03-16

    Logged In: YES
    user_id=351330
    Originator: NO

    Yes, the assumption from Apple is that if you have taken over the screen to the point where the Dock cannot be shown, then you really want all keystrokes too.

    I've thought about it some more, and I think what I suggested earlier is solid, with a slight change. Keep the existing behavior if the user has a single monitor. If the user has multiple monitors, take over only a single one UNLESS a hidden default is set to take them all over. That default will NOT be exposed in the UI, but can be mentioned in the docs. It's very geeky.

    And let's not cache the monitor count just in case the user attaches/detaches during a session.

     
  • Jared McIntyre

    Jared McIntyre - 2007-03-25

    Logged In: YES
    user_id=751989
    Originator: NO

    Is there a way to forward those messages back to the system? Or tell the system that we didn't handle it?

     
  • Jason Harris

    Jason Harris - 2007-03-26

    Logged In: YES
    user_id=351330
    Originator: NO

    We *want* to catch those messages when we're in fullscreen, and we don't unless we capture all displays. Things such as the keystroke that shows/hides the dock, or activates spotlight or Quicksilver. When you're fullscreen, you want those forwarded on to the host. This is functionality that I always use in Chicken.

    It's possible that we could use CGEventTap to grab these regardless of the capture mode. That would probably be the best bet, but I don't have any experience with that API and I hear anecdotally that it can be tricky. Doing what I outlined in my last message still seems like the simplest and best bet.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks