the mouse is locked to the screen. We can't tell if a half-
duplex key is physically down and logically down just means
it's active so there's no point in letting it lock the mouse
to the screen.
from a windows server. Was converting ctrl+alt on windows to
mode switch on the server. No longer doing that; windows clients
will interpret ctrl+alt as AltGr and other clients will just see
ctrl+alt. Also made the right alt key mode switch on windows
servers in case the user wants to force a mode switch, but that
means the right alt key no longer acts as alt on clients.
more robust now. Also added handling of Super modifier key and
changed windows keys to map to Super instead of Meta, which is
the default on my keyboard.
Made extensive changes to the launcher to provide more control
over setting up auto-start and it now saves configuration to
the user's documents directory if auto-starting at login and
saves to the system directory if auto-starting at boot.
Replaced MapVirtualKey() with table lookup to work around that
function's lack of support for extended keyboard scan codes.
Added first cut at support for AltGr.
warp the mouse to the primary screen. entering the primary
screen causes the primary screen's window to be hidden. the
deadlock occurs because hiding the window seems to post a
message then wait for it to be handled (or possibly it won't
send a message while a posted message is being handled).
thread A locks the mutex, warps the mouse, the hides the window.
thread B begins processing the mouse warp then tries to lock
the mutex. thread A is waiting on the event loop owned by B
while B is waiting on the mutex owned by A. this fix simply
hides the window asynchronously. however, there may be other
ways to cause a similar deadlock that have not been found.
from config.h if available (which means version is now a
string, not three integers). Changed version to 1.0.0 and
protocol version to 1.0. And added MAINTAINERCLEANFILES
to makefiles to remove generated files.
would fail to open in such a way that it could never succeed
but it'd never stop retrying. now terminating when open fails
such that it'll never succeed.
synergy.cpp and server.cpp into cmd/synergyd as synergyd.cpp.
Moved and renamed related files. Moved remaining source files
into lib/.... Modified and added makefiles as appropriate.
Result is that library files are under lib with each library
in its own directory and program files are under cmd with each
command in its own directory.
