We can get races with clipboard managers in the server that is very
confusing to the user.
When the clipboard changes locally, we tell the server to drop the old
clipboard (as it is now lost). But we don't send over the new clipboard
until we get focus again, in order to not leak more data than necessary.
This causes some clibpoard managers to take over ownership in order to
avoid an empty clipboard. And this takes precedence over the new client
clipboard as it happened later. Effectively reverting the clipboard the
user sees.
Avoid all of this by simply ignoring the server when we don't have
focus. This is likely what users expect anyway as they expect their
currently focused application to control the clipboard, not vncviewer in
the background.
The system steals keyboard events for certain system keyboard shortcuts,
e.g. Cmd+Tab. Unfortunately this isn't considered a focus loss, so we
don't realise we've lost a few keyboard events and can end up in a
confused state.
Fortunately it is possible to detect when this happens and reset the
keyboard state, just like we do when focus is lost.
We have a timer after Ctrl is pressed in order to see if an Alt will
come right after. Ctrl + Alt is what windows sends for AltGr.
If a key other than Alt was pressed we knew that we could cancel this
timer, this commit extends that to mouse events too.
Since this detection breaks the true order of events we want to make
a decision as fast as possible.
Not every mouse has three buttons e.g. laptops. Some OS might not
have support for middle mouse button emulation.
This commit adds emulation for middle mouse button when pressing both
left and right mouse button simultaneously.
We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.
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.
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.
Use PixelBuffer objects as the interface for encoders and decoders
This avoid a lot of unnecessary middle men. This also pushes the
responsibility for pixel format conversion into the encoders and
decoders. The new bufferFromBuffer() is used for direct conversion,
rather than PixelTransformer/TransImageGetter.
Gets rid of a loooot of code and complexity.
Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.
If the client and server are using identical pixel formats, then perform Tight decoding directly into the viewer's back buffer, rather than going through the slow fillRect/imageRect routines.
- Changes behaviour of context menu to be reinitialize
before display with intial states.
- Fixes for fullscreen contextmenu item to show the
current fullscreen state as it was done in the
old viewer.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4670 3789f03b-4d11-0410-bbf8-ca57d06f2519
The new viewer stores the framebuffer in a native format, instead of
converting it on each render like the old one. That means we have to change
how we deal with colour maps and make sure it is updated before any changes
to the framebuffer.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4589 3789f03b-4d11-0410-bbf8-ca57d06f2519
Implement optimised drawing operations for OS X. Didn't see any reduction in
CPU usage unfortunately, but at least we're now using the native pixel format
of our server which avoids a conversion on the server side.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4504 3789f03b-4d11-0410-bbf8-ca57d06f2519
Flushing screen updates after 100 ms turned out to be too aggressive and
just gave an annoying window blinds effect that made things difficult to
read. Reduce things to 500 ms, which should be sufficient to tell that the
session isn't completely frozen.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4495 3789f03b-4d11-0410-bbf8-ca57d06f2519
Handling a full range of keys for the menu key is not as trivial in FLTK as
with raw X11, so do what the Windows client did and restrict the available
keys to just the function keys.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4444 3789f03b-4d11-0410-bbf8-ca57d06f2519
Pierre Ossman
Samuel Mannehed
Alex Tanskanen
DRC
Henrik Andersson