The parameter files are used to make sure changes in the UI are
persistent. Storing anything else results in behaviours that the
user has no easy way of changing.

It is already hidden in the UI, so make sure it also is gone as a
command line parameter. This follows the behaviour of the similar
sendPrimary parameter.

We need to make sure it is null terminated on truncation. We also
need to avoid giving a too large size argument or modern gcc will
complain.

It's not common knowledge these days how X geometry is specified, and
even the man page X(7) is missing on many systems now.

FLTK has some options (that we've also documented in the man page)
that should be mentioned in the --help output.

We can use a dummy value here as we set up the buffer and stride
further down in the constructor.

We always sync when we get focus, so this code path is really only
for when the server announces LED state support after we already
have focus.

Make sure we only handle this specific scenario as otherwise we
could end up syncing twice, which just toggles things back and forth
and ends up syncing incorrectly.

Logging revealed that a few empty damage regions are emitted on startup. Those don't need to be rendered to the Surface pixmap.

The Pixmap is filled in as updates from the server arrive. Before the first full update, it would contain undefined contents, which would be rendered onto the ViewPort.
Clearing the Pixmap is only done on startup and when changing the server resolution, so it's not performance critical.

These are not allowed in C++, and have been made optional in C11.
So let's just get rid of them and any issues they may cause.

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.

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.

Our XRender code assumes a certain pixel layout which was not
guaranteed on big endian systems. The previous workaround only worked
for some cases, so fix this properly now.

Our main web site now supports https, so update all references.

We've had support for unix sockets for a while now. Make sure this
is reflected in the -help output and the man page.

Also make some minor tweaks to the section to get everything in
sync with reality.

The compiler isn't smart enough to figure all of these out, so
restructure things a bit to avoid warnings.

We should be looking at the physical monitor layout, not the current
RFB layout. The latter might not be in sync with the local monitors.

Remnants from an earlier version of the code.

Makes sure it is readable in a multi screen configuration, as otherwise
it might end up crossing multiple screens.

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.

It can get a bit intrusive for experienced users, so try to reduce
the impact of it.

We had partial coverage for vncviewer/ already, but fix up the last
pieces.

We put the try/catch as close as possible to the writes in all
other case, so make sure this code also follows that pattern.

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 might not get one from the default configuration (we might not have
a default configuration at all), so make things more robust.

Grabbing (and ungrabbing) the keyboard generates fake focus events
with modern versions of Xorg. This causes an infinite loop since we
update the grab status on focus events.

Work around this by ignoring these fake events.

It is no longer a workaround but rather intended behaviour.

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.

The user might just want to load a bunch of settings and not
initiate a connection.

Make the code simpler by handling it just like any escaped character.

We decoded "\\n" as "n" rather than "\n".

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

The user can specify a tigervnc configuration file as an argument to the
viewer. Previously the viewer assumed this to be a server, but now we
will first check if there is any file matching the given argument. If
so, try to load the content of that file, like we normally do.

Fixes issue #38.

Makes the code more general and not directly tied to specifically
TCP sockets.