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.
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.
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.
Avoid duplicating all the memory mangement, and instead use the
BufferedOutStream as a base clase for all out streams that need an
intermediate buffer.
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.
Safely discard large (extended) clipboard contents
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.
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.