Fixed handling of AltGr from Windows' touch keyboard
We need to test this always in order to catch Ctrl+AltGr, and to
handle release of the key properly. Hopefully there isn't any other
case where VK_MENU is sent without a scan code.
For KDE we can sometimes get a bunch of stray FL_LEAVE events before
gaining focus. Sending their included button information gets things
in the incorrect order with regard to other synchronisation we do on
focus. So just ignore buttons as the only information we want out of
the leave information is a position update.
Setting Ctrl or Alt key on menu only sends the key press, and the
state is lost when focus is lost and recovered.
This checks the menu variable and sends the keys again if needed.
We should start by getting the remote end in sync with the actual
keyboard state. This would work randomly before depending on if we
got the first LED state message before or after we got focus.
We don't want to surprise the user with unexpected clipboard changes
when vncviewer is in the background, and it is both wasteful and
possibly insecure to inform the server of every clipboard update
when the user isn't interacting with it.
Try to properly detect the fake CtrlL+AltR sequence Windows sends
when pressing AltGr. This allows us to send more accurate key
events over to the server.
This adds the basic infrastructure and handshake for the QEMU
Extended Key Events extension. No viewer or server makes use of
the extra functionality yet though.
Some platforms draw directly to the screen, which means that updates
will flicker if we draw multiple layers. Prevent this by first
composing the update on a hidden surface.
Delegate decoder object management to a separate class
Done in preparation for multi-core decoding. Keeps the complexity
out of the other classes. This also moves ownership of the
framebuffer in to CConnection. It's the CConnection object that is
aware of the threads and how to synchronise with them. Therefore
the ownership of the framebuffer must also be there to make sure
it isn't deleted whilst threads are working.
Normally we only display screen changes once we have the updates for
the entire screen. This may give the impression that the viewer is
hung though. So display the partial data if the update is taking to
long to arrive.
Change fillRect() to take a buffer instead of a pixel
There has been some confusion if fillRect() should accept a buffer
or a pixel. This can cause misrendering if your data is not in the
native endian order. A buffer makes more sense here though, and
is what most of the callers are already assuming, so change the
API to follow that.
Use exceptions rather than asserts for for "normal" errors
Although these are rare, they are still not indicative of bugs so
an exception (which ends up in the log and might also be shown to
the user) is more appropriate than an assert. Asserts should only
be used to catch blatant API misuse and similar.
This key requires a bit extra care on Windows. We get wildly
different messages depending on if Alt is pressed or not. The symbol
chosen now follows the standard behaviour on X11.
Disable input methods when the viewport is focused
Input methods are way too complex for us to map them to the VNC
protocol in any sane manner. Best just to disable them and rely
on simple keyboard behaviour when the viewport is active.