This should be happening implicitly, but isn't always for some reason on
macOS 13.

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.

Delay startup of VNC sessions until user databases are up and running.
This is the same ordering that GDM imposes to make sure users can
actually log in.

We might often fail to find a matching X11 keycode when the client has
a different keyboard layout and end up with no key event. To avoid a
failure we add it as a new keysym/keycode pair so the next time a keysym
from the client that is unknown to the server is send, we will find a
match and proceed with key event. This is same behavior used in Xvnc or
x11vnc, although Xvnc has more advanced mapping from keysym to keycode.

We don't want any stray exceptions as we are cleaning up, so handle any
still pending decoder errors by just logging them. We are already
shutting down so there is no need to abort the connection here.

They don't get access bits until they've been authenticated, so avoid
doing any checks on clients in those early states.

It probably wanted to say "newer", but let's say "later" instead. Other
building requirements say "later".

Avoid having to update this manually.

These require a key to have been set up on the server beforehand, so
they do not give a good default experience as clients will be unable to
connect.

This is missing in the CentOS 9 repositories for some reason. Download
it directly from the build system until this can be fixed.

The older versions are getting deprecated, so make the switch.

These files are checked in, so there is no need to build these for
packaging.

This is needed to correctly handle the spec file, so it needs to be
installed before we parse it for build dependencies.

We do all the prep work in the image step for the other targets, so
let's do the same here.

This is a build requirement, not a fundamental system thing, so it
should not be handled here.

The image has been updated, so this workaround is no longer needed.

The accessor functions are called value() for all standard FLTK widgets,
so let's keep that theme here as well.

Follow upstream FLTK naming to more clearly indicate that this is a
general widget and not TigerVNC specific.

These are general things and not specific to TigerVNC, so let's move it
to the fltk specific directory for clarity.

These have nothing to do with layout, so let's split them to their own
file.

Let's separate TigerVNC specific things from stuff that could be part of
upstream FLTK. These are files that we would like to collaborate with
other FLTK users, so they are more liberally licensed and avoid using
TigerVNC specific things.

Try to organise this better to make it clear which dependencies are
ours, and which we've gotten just because Xvnc is based on xorg-server.

Also update the dependency list to the current state of things.

This is what upstream does, so let's add it in case some dependency is
added implicitly by the Debian build tools somewhere.

This is done for us, so stop having explicit lists that we forget to
update properly.

Follow the format upstream Debian/Ubuntu uses.

We want it to complain loudly if a dependency is missing, not just
quietly continue on.

This is to make the code more tolerant of typos when entering a hostname

It is generally pulled in as a requirement from GnuTLS, but let's be
explicitly now that we make use of nettle directly.

pkg-config support was added very recently to gmp, so a lot of platforms
we want to support won't find gmp this way.

It is a (weird) dependency of nettle, and not part of nettle itself. So
split it to a separate module for clarity.

The order is important in the servers, so make sure the man pages follow
the code properly.

This was accidentally disabled in 81e114f.

This call should have been preceeded by hasData() or avail(), just like
all other accessor functions.

We should scope these as narrowely as possible to avoid side effects.