events to other hook functions, which broke some tools like objectbar.
Second, windows key processing was fixed. Previously pressing and
release the key would only send a press event, locking the user onto
the client window; also, the win32 server treated as a Meta modifier
instead of a Super modifier, which broke any use of it as any kind of
modifier key. Third, added hacks to support several key combinations
on windows 95/98/me that are treated specially by windows, including
Alt+Tab, Alt+Shift+Tab, Alt+Esc, Alt+Shift+Esc, Ctrl+Esc, and any
combination using the windows key like Win+E and Win+F but not
Ctrl+Alt+Del. Fourth, scroll lock only locking to the client (which
only happened when using a synergy server on windows) has been fixed;
unfortunately the solution causes a lot of screen redraws for some
reason. Finally, there's been a fix to clipboard handling that may
or may not fix a problem where the clipboard would stop transferring
between systems after a little while. I can't be sure if it fixes
the problem because I can't reproduce the problem.
entering the loop waiting for it to deactivate. The failure
to check was causing the screen saver code to kick in when
the screen saver timeout occurred, even if the screen saver
wasn't enabled (because Windows still sends the screen saver
activating message for no good reason when the screen saver
is disabled).
when not on the primary monitor. This should eliminate the flicker
between virtual display 0,0 and the correct position. While this
allows the user to confuse synergy by using the client's mouse,
synergy recovers quickly and easily from any confusion.
a race condition where the synergy server updates the mouse
position but the synergy hook later receives a mouse update from
before the position change (i.e. out of order).
use Xlib to convert an unmatched keysym to upper and lower case and
use whichever, if any, is not the same as the original keysym.
This supports case conversion in any language that Xlib supports
it in.
mouse behavior on multimonitor windows systems. Those errors
broke synergy on all windows systems running as a server.
Also added an attempt to reduce the occasional jump that can
occur when switching screens when windows is the server.
code in a conditional for moving left that blew an assert verifying
that the mouse position was really on the screen if the neighbor
screen wasn't connected.
After that was fixed there was another problem when one screen
linked to another which then linked (in the same direction) to
itself. If the latter screen wasn't connected then it'd get into
an infinite loop.
It was doing that already if started through synergy but not if
started by something outside of synergy. In particular, if you
use `xscreensaver-command --activate' synergy used to send fake
mouse motion events every 5 seconds to deactivate it. That's
unlikely to be what the user wanted, especially if the locking is
enabled since it would force the password dialog to appear.
As before, it's recommended that client screens not use locking
because xscreensaver will not deactivate without getting a
password even if we make the request through a programmatic
interface. Presumably that's for security reasons but it makes
life harder for synergy.
crs