and Xinerama correctly. Also was using '#if defined(...)' instead
of '#if ...' for testing configure macros in some places. This
yields the wrong answer if the macro is set to 0, which means
missing/disabled.
events when receiving any event with message == 0 when the system
doesn't use old style mouse wheel events. Some programs (especially
the flash plugin) would send events with message == 0 causing
undesired wheel scrolling.
the cursor wasn't being parked in the center of the main screen
but instead at the center of the total display surface. This could
place it off or dangerously close to the edge of the transparent
window that covers the main screen and prevent synergy from capturing
mouse motion.
duplex keys but broke primary screens. This fixes both and
also ensures that the primary screen updates its shadow toggle
modifier state when leaving so the secondary screens get the
correct toggle modifier state. Together these fix some strange
inconsistencies in toggle state across screens.
for class visibility on pointers to member function 'using the
qualifying scope of the name itself.' what this means is if method
'prot' is declared protected in class A and B inherits from A then
a method in B cannot use &A::prot but can use &B::prot. Synergy
now does this in the one place it had not.
keys are mapped to the same button. For example, the backslash
virtual key shares a button with some other virtual key on british
english key mappings. Synergy could end up using the wrong virtual
key. In the given case, the other virtual key produced no character
at all. To determine which virtual key should really be mapped to
a button we map the button back to a virtual key and see if it's the
virtual key we started with.
Also fixed mapping of pause key. Previously, windows+pause sent to
a win32 client wouldn't bring up system properties like it should.
non-blocking connect is available for writing (i.e. the connection
was successful) when the connection has actually failed. This
caused synergy to rapidly retry connecting. This change makes
synergy check for a connection error whether one was reported or
not. Thankfully, OS X does correctly set the socket error state
when it bogusly reports a successful connection so we can tell the
connection failed.
a synergy client on that OS and pointed it at a system that wasn't
listening for connections then instead of the connection attempt
failing with 'connection refused' the system would claim the
connection succeeded. A subsequent read would reveal the problem
and synergy would "disconnect" and retry, causing the CPU to spin.
The system does correctly set the socket error state so this
workaround checks for socket errors when connecting whether or not
select reports an error state.
Also, sometimes the system doesn't claim success but doesn't report
an error. Synergy eventually times out these attempts.
detect synergy hotkeys but a design flaw in X11 makes it problematic
with many applications. We'll have to fall back to the more
traditional XGrabKey when the time comes.
crs