Try to follow the actual padding that FLTK adds to these widgets.

The extra one pixel on each is because of a bug in FLTK's focus drawing
code, where the box is always one pixel too small in both dimensions.

This is how GNOME does things, so let's do the same so things look
similar.

To conform with how e.g. GNOME sets its margins.

This makes the code much cleaner, and easier to update.

Makes it easier to adjust the UI from a central place.

Makes it easier to adjust the UI from a central place.

Outlines are no longer commonly used. Instead visually separated
headlines are the norm.

Classical tabs are very dated. They are also a practical problem as you
get very limited in the numbers of tabs we can have, and how long the
text can be on them.

Switch to one popular modern model with a list on the left instead where
pages can be selected.

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.

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.

Avoid duplicating all the memory mangement, and instead use the
BufferedOutStream as a base clase for all out streams that need an
intermediate buffer.

Allow subclasses to call it, instead of it being strictly internal. This
is useful when a subclass can only provide data in minimum sized chunks.

It might not be compiled in, so the height needs to be dynamic.

We lacked an entry for one of these, and the magical swap that macOS
does for unknown reasons.

Makes it easier to compare changes with what people normally run.

Add also missing <stdlib.h> where required.

Fix edge of dot cursor in Java vncviewer

This commit changes the color of the edges of the dot cursor in the Java
version of vncviewer from fully transparent to white, bringing it in
line with the C++ native version.

Might be useful for testing in some cases. Note that the Windows and
Linux binaries will depend on libraries from the build environment. So
the user will need to match those manually.

The previous commit was incorrect in that it overrides automake's
dependency list, rather than adding to it. So we need to make sure
things are duplicated between Xvnc_DEPENDENCIES and Xvnc_LDADD as
appropriate.

Use the same approach as the Xorg binary to keep things familiar.

These aren't crucial for a clean build, but must be set for Xvnc to be
properly rebuilt if anything in the Xorg tree changes. automake doesn't
properly deduce these automatically from Xvnc_LDADD, unfortunately.

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.

Avoid having to buffer everything we want to discard, and instead do it
piece by piece. This is more efficient, and avoids hitting any limits on
the buffering.

Note that this is safe here because we already know we have all the
compressed data. It would not be safe for a general input stream.

These streams both need to change the corking state temporarily, but it
is important it is restored to the previous state or things might get
messed up.

For the zlib stream it would just leave things uncorked, which still
works but is less efficient.

But for the TLS stream it might make things very unresponsive as the
corking might be left on permanently, delaying packets indefinitely.

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

There is no point flushing when corking was enabled, as we might then
push out a small buffer that the corking otherwise would have preserved.

It seems MFT h264 decoder does not support frame cropping. Which
means that if frame width or height is not multiple of 16 then
decoded output can potentially be used with wrong offset. This
code adds explicit parsing of SPS to extract cropping information
to use, and will apply cropping if reported size differs from
expected.