This question appears every few months in my life, as I ponder a way to reduce physical complexity through software complexity, wishing to trade a cluttered desktop with a cluttered process list. To be fair, Synergy does exist for the Mac. However, the Synergy port that was written is not a native Cocoa or Carbon application, but instead the port uses X Windows, which also requires installing Xcode, and thus sacrificing some portion of the user's hard drive to appease the gods of software dependency. The problems seen with using the X Windows port of Synergy on the Mac go much deeper than merely wasting hard drive space, which is a precious commodity for any laptop user -- a population that I feel I represent quite well, as do many of the users on this forum. No, the problem is that X Windows on the Mac has utterly no concept as to what other windows are littered about on the screen, as Mac OSX's window manager keeps up with a merged list of it's own windows in addition to X Windows' windows, while X Windows is left in the dark as to anything outside of the X Windows sandbox. The reasons for this are simple and easy to understand; X Windows is an add-on product and in the realm of software, one does not desire to have an add-on component cause instability to what amounts to core functionality of an operating system. As to the motivations of programmers, and why no one has written a native port of Synergy, I cannot answer. People are wont to do as they are motivated to do. My solution for the problem is two-fold: To place a bounty on the prize of having a native port of Synergy written, tested, and made free to the world and to plant a seed for an alternative to writing a native port of Synergy. Such are the limits of my capability at this time; I am neither a programmer nor do I aspire to be one. I do like to think of myself as "an idea rat". When an idea comes along that I am incapable of doing much with myself, I feel compelled to share it with the outside world, in the hopes that my addled mind continues to contribute to that world.
My idea is therefore to make (ab)use of the built-in VNC functionality of Mac OSX to implement or simulate keyboard and mouse input, as VNC handles this function quite well. VNC can also deal with a sudden change in the cursor position, and in the short run, may be used as a genuine hack to deliver the same functionality without coding an entire application.