The need for these must have got lost somewhere in the type cleanup.

These will always be byte streams at heart, so let's try to keep them
with a proper type. Should make it clearer how they will be used.

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.

This mimics how some system functions (like inet_ntop()) work, and
avoids complexity around ownership of the returned string buffer.

The downside is that the string must be consumed directly as it will be
overwritten on the next call, but that is not an issue with the current
usage.

Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.

This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.

This was accidentally disabled in 81e114f.

The socket might not be the stream actually used, e.g. when we are using
TLS. Make sure we cork the proper stream to get all the benefits of
corking.

Uncorking implicitly flushes, so we don't need this.

FLTK has a lot of synchronous stuff (like dialogs), which mean that the
main loop might be run recursively in some cases. If there is data
available on our socket then CConn::socketEvent() will be called
constantly in a busy loop.

Avoid this by removing socket notifications whilst we are processing
data.

vncviewer previously had a the same localized error message duplicated
on a bunch of places. Pull these duplicates out into a single function.

This change makes it possible for re-synchronizing the remote cursor on
the vncviewer when in fullscreen mode. This is done by locally moving
the cursor position to what the server thinks it should be.

Now SDL games should work!

It took way too long to converge on a sane value, so reduce the window
by a factor of ten. This seems to work smoothly.

Include something more user friendly when we need to fail fatally and
not just the technical error.

Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.

Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).

Now measures over an entire update, which should hopefully give us more
stable values. They are still small values for fast networks though so
increase precision in the values we keep.

Some systems (like TLS) need to send some final data before closing
a connection. Make sure this is properly handled by cleaning up the
security object before closing the underlying network socket.

Otherwise such clients cannot use Scroll Lock at all, and that is
probably worse than any effects we might get from getting out of sync.

The input stream might no longer be the raw socket, so we need to
query what's currently active. That wrapping stream might have its
own buffering and may have more data even if the socket is drained.

Change the internal clipboard API to use a request based model in
order to be prepared for more advanced clipboard transfers.

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.

ServerParams should contain the server state and not information about
client settings or capabilities. Move those things up a level to the
CConnection object.

No need to have one setting for each extension. All the client code
needs to indicate is if it supports resize. The common code can then
map this to relevant extensions.

These were either completely unused, or always true.

It's a generic client thing, so abstract it in to the common library.
Makes it easier to integrate with other common code.

Avoid using the callbacks used for runtime changes for the initial
setup. They weren't really useful anyway as you could not allocate
a framebuffer without also knowing the pixel format. So make things
more clear by letting serverInit() get the initial settings.

Add an explicit callback for subclasses to do their startup in. This
makes it easier to do proper ordering, and avoids mistakes.

This method was only really useful when continuous updates was active,
so let's rely on a single extension rather than two.

We need to track different things in the server and client, so
separate things to two independent structures to keep things more
clear.

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.

Patch originally by Dag-Erling Smørgrav for University of Oslo.

That way both incoming and outgoing clipboard are both in the same
place, making things clearer.

The VNC servers aren't great at getting full frames with each update,
so avoid calling it "frames per second" in the statistics as that
can be misleading.

Add a new parameter 'alertOnFatalError' which guards
the displaying of the GUI alert on fatal errors, and
thus when false just gives the textual error.

Now I can do:

  while true
  do
    vncviewer alertOnFatalError=false vm:0
    sleep 1
  done

and it'll reappear when my VM appears without me getting error
dialogs.

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
--

Adds an optional graph to the viewer to display current frame rate,
pixel rate and network bandwidth. Makes it easier to debug and test
performance related issues.

This will allow us to use better formats that preserve the entire
alpha channel.

The complex logic waiting for events didn't result in any added
performance, so use the simpler approach.

There were still some circumstances where we could get stuck reading
data and not respect close events properly. Move that logic to a more
central place in order to make it more reliable.

Previously the incoming clipboard was unconditionally set to both
the PRIMARY and CLIPBOARD selection. This isn't always what the
user want, so make it configurable.

We need to make sure the display server has finished reading our
previous update before we overwrite the buffer with the next update.

We need more callbacks for correct operation of multi-threaded
rect decoding.

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.

It should be possible to exit the viewer even if the network has
stalled in the middle of a transfer.