We mostly use classical C strings, but the memory management around them
can get confusing and error prone. Let's use std::string for the cases
where we need to return a newly allocated string.
The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.
Avoid direct access to the screen dimensions and layout so that we
can make sure it stays sane. This also makes sure the layout is
properly updated when we only get the screen dimensions from 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.
Eliminate GCC signed/unsigned warnings related to encodings: The
encoding in the RFB protocol has always been signed, and signed values
are also used in the specification (ie DesktopName = -307 etc). In the
code, however, unsigned types were used in a number of places, but not
all, which causes warnings. This patch fixes the problem by switching
to signed values everywhere.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3968 3789f03b-4d11-0410-bbf8-ca57d06f2519
Remove the "video" feature and its associated custom JPEG handling.
Having the client specifiy the video region is conceptually wrong
and a problem like this should be handled by better encoding selection.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3635 3789f03b-4d11-0410-bbf8-ca57d06f2519
[Enhancements, refactoring] Rationalized functions to control video
rectangle selection and default video rectangle. Added more logging and
improved error checking in the related code.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2753 3789f03b-4d11-0410-bbf8-ca57d06f2519
Removed support for continuous updates, a TightVNC-specific RFB protocol
extension. That extension used to send framebuffer updates continuously, not
waiting for clients' requests. However, it showed bad results with
low-bandwidth connections, due to lack of proper data flow control.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2581 3789f03b-4d11-0410-bbf8-ca57d06f2519
Initial implementation of continuous updates in the server code. This code does not handle framebuffer size changes properly yet. Also, the server does not send the client EndOfContinuousUpdates message yet (documented in doc/rfbproto.tex).