Avoid logging pre-verstring EPIPE from sharing downstreams.

If you use the new 'plink -shareexists' feature, then on Unix at least
it's possible for the upstream to receive EPIPE, because the
downstream makes a test connection and immediately closes it, so that
upstream fails to write its version string.

This looks a bit ugly in the upstream's Event Log, so I'm making a
special case: an error of 'broken pipe' type, which occurs on a socket
from a connection sharing downstream, before we've received a version
string from that downstream, is treated as an unusual kind of normal
connection termination and not logged as an error.

New Plink operating mode: 'plink -shareexists'.

A Plink invocation of the form 'plink -shareexists <session>' tests
for a currently live connection-sharing upstream for the session in
question. <session> can be any syntax you'd use with Plink to make the
actual connection (a host/port number, a bare saved session name,
-load, whatever).

I envisage this being useful for things like adaptive proxying - e.g.
if you want to connect to host A which you can't route to directly,
and you might already have a connection to either of hosts B or C
which are viable proxies, then you could write a proxy shell script
which checks whether you already have an upstream for B or C and goes
via whichever one is currently active.

Testing for the upstream's existence has to be done by actually
connecting to its socket, because on Unix the mere existence of a
Unix-domain socket file doesn't guarantee that there's a process
listening to it. So we make a test connection, and then immediately
disconnect; hence, that shows up in the upstream's event log.

Actually set the 'got_verstring' flag in sshshare.c!

For each connection to a downstream I had a flag indicating that we'd
sent a version string to that downstream, and one indicating that we'd
received one in return. But I never actually set the latter to TRUE -
which was OK, as it turned out, because I never used it for anything
either.

Now I do want to use it, so I'd better actually set it :-)

Factor out ssh_hostport_setup().

This is the part of ssh.c's connect_to_host() which figures out the
host name and port number that logically identify the connection -
i.e. not necessarily where we physically connected to, but what we'll
use to look up the saved session cache, put in the window title bar,
and give to the connection sharing code to identify other connections
to share with.

I'm about to want to use it for another purpose, so it needs to be
moved out into a separate function.

Factor out ssh_share_sockname().

This is the part of ssh_connection_sharing_init() which decides on the
identifying string to pass to the platform sharing setup. I'm about to
want to use it for another purpose, so it needs to be moved into a
separate function.

Fix misplaced separator in GTK3 dialog boxes.

When I abandoned GtkDialog for GtkWindow (in dc11417ae), I manually
added a horizontal GtkSeparator between the content and action areas.
Or rather, I tried to - but I forgot that gtk_box_pack_end works in
the opposite order, so that you have to add the bottom-most element
first and then the one you want to appear above it. So my separator
was below the action area, rather than between it and the content
area.

Fix window resizing in GTK 3 PuTTY.

In GTK 3, it was impossible to resize the window smaller than it
started off, because the size request on the drawing area was taken as
a minimum. (I can't actually remember how the GTK 2 version doesn't
have this problem too.)

Fixed by instead setting the initial window size using
gtk_window_set_default_geometry() (having first set up the geometry
hints to reflect the character cell size).

Sanitise bad characters in log file names.

On Windows, colons are illegal in filenames, because they're part of
the path syntax. But colons can appear in automatically constructed
log file names, if an IPv6 address is expanded from the &H placeholder.

Now we coerce any such illegal characters to '.', which is a bit of a
bodge but should at least cause a log file to be generated.

Shout more loudly if we can't open a log file.

A user points out that logging fopen failures to the Event Log is a
bit obscure, and it's possible to proceed for months in the assumption
that your sessions are being correctly logged when in fact the
partition was full or you were aiming them at the wrong directory. Now
we produce output visibly in the PuTTY window.

Centralise stripslashes() and make it OS-sensitive.

I noticed that Unix PSCP was unwantedly renaming downloaded files
which had a backslash in their names, because pscp.c's stripslashes()
treated \ as a path component separator, since it hadn't been modified
since PSCP ran on Windows only.

It also turns out that pscp.c, psftp.c and winsftp.c all had a
stripslashes(), and they didn't all have quite the same prototype. So
now there's one in winsftp.c and one in uxsftp.c, with appropriate
OS-dependent behaviour, and the ones in pscp.c and psftp.c are gone.

Command-line options to log sessions.

Log files, especially SSH packet logs, are often things you want to
generate in unusual circumstances, so it's good to have lots of ways
to ask for them. Particularly, it's especially painful to have to set
up a custom saved session to get diagnostics out of the command-line
tools.

I've added options '-sessionlog', '-sshlog' and '-sshrawlog', each of
which takes a filename argument. I think the fourth option (session
output but filtered down to the printable subset) is not really a
_debugging_ log in the same sense, so it's not as critical to have an
option for it.

Use a Cairo image surface as a client-side cache.

In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo
image surface which lives on the client; then we either blit directly
from that to the window (if we're in GTK3 mode, or GTK2 without
deprecated pieces of API), or else we blit from the Cairo surface to
the server-side pixmap and then from there to the actual window.

In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly
to the server-side pixmap using the GDK drawing API, then blit from
there to the window. But there is one change, namely that the blit is
no longer done proactively - instead, we queue a redraw of the
affected rectangle, and wait until we're called back by the expose
handler.

The main aim of all this is to arrange that the only time we ever draw
to the real window is in response to expose/draw events. The
experimental GTK3 OS X port stopped working a week or two ago (I
presume in response to an OS update) with the symptoms that attempts
to draw on the window outside the context of a "draw" event handler
just didn't seem to work any more; this change fixes it.

In addition to that benefit, this change also has obvious performance
advantages in principle. No more expensive text rendering in response
to an expose event - just re-copy to the window from the bitmap we
already have, from wherever it's stored that's nearest.

Moreover, this seems to have fixed the significant performance problem
with X server-side fonts under GTK. I didn't expect _that_! I'd
guessed that the approach of downloading character bitmaps and
rendering them manually via Cairo was just inherently slow for some
reason. I've no real idea _why_ this change improves matters so much;
my best guess is that perhaps there's an overhead in each drawing
operation to a GDK Cairo surface, so we win by doing lots of
operations to a much faster image surface and then batching them up
into one GDK Cairo operation. But whyever it is, I'm certainly not
complaining!

(In fact, it now seems to be noticeably _faster_, at least on my usual
local X displays, to draw server-side fonts using that technique than
using the old GDK approach. I may yet decide to switch over...)

Fix spurious EAGAIN in Plink host key (and other) prompts.

Plink sets standard input into nonblocking mode, meaning that read()
from fd 0 in an interactive context will typically return -1 EAGAIN.
But the prompt functions in uxcons.c, used for verifying SSH host keys
and suchlike, were doing an unguarded read() from fd 0, and then
panicking and aborting the session when they got EAGAIN.

Fixed by inventing a wrapper around read(2) which handles EAGAIN but
passes all other errors back to the caller. (Seemed slightly less
dangerous than the stateful alternative of temporarily re-blockifying
the file descriptor.)

Don't try to agree a MAC we'll never use.

If we've chosen the ChaCha20-Poly1305 option for a cipher, then that
forces the use of its associated MAC. In that situation, we should
avoid even _trying_ to figure out a MAC by examining the MAC string
from the server's KEXINIT, because we won't use the MAC selected by
that method anyway, so there's no point imposing the requirement on
servers to present a MAC we believe in just so we know it's there.

This was breaking interoperation with tinysshd, and is in violation of
OpenSSH's spec for the "chacha20-poly1305@openssh.com" cipher.

Split ssh2_cipher's keylen field into two.

The revamp of key generation in commit e460f3083 made the assumption
that you could decide how many bytes of key material to generate by
converting cipher->keylen from bits to bytes. This is a good
assumption for all ciphers except DES/3DES: since the SSH DES key
setup ignores one bit in every byte of key material it's given, you
need more bytes than its keylen field would have you believe. So
currently the DES ciphers aren't being keyed correctly.

The original keylen field is used for deciding how big a DH group to
request, and on that basis I think it still makes sense to keep it
reflecting the true entropy of a cipher key. So it turns out we need
two _separate_ key length fields per cipher - one for the real
entropy, and one for the much more obvious purpose of knowing how much
data to ask for from ssh2_mkkey.

A compensatory advantage, though, is that we can now measure the
latter directly in bytes rather than bits, so we no longer have to
faff about with dividing by 8 and rounding up.

New script to generate OS X icon files.

The Xcode icon composer doesn't seem to exist any more in modern
versions of Xcode, or at least if it does then it's well hidden and
certainly doesn't live at the top-level path at /Developer where web
pages still claim it can be found.

There is a free software 'libicns' and associated command-line tools,
but they're large, complicated, picky about the exact format of PNGs
they get as input, and in any case a needless extra build dependency
when it turns out the important parts of the file format can be done
in a few dozen lines of Python. So here's a new macicon.py, and
icons/Makefile additions to build a demo icon for OS X PuTTY, as and
when I finally get it working.

Also I've deleted the static icon file in the neglected 'macosx'
source directory, because this one is better anyway - the old one was
appalling quality, and must have been autogenerated from a single
image in some way.

Clean up GTK keyboard event diagnostics.

When I introduced the KEY_EVENT_DIAGNOSTICS system last month in
commit 769600b22, I somehow didn't notice that it sat next to an
existing system of ifdefs labelled KEY_DEBUGGING, which did some
things worse but some things better.

Now I've expanded both of those into a fairly complete system of
diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and
made them use debug() rather than printf() so that in situations where
no standard output is available I can still retrieve the diagnostics
from debug.log.

Revert accidentally committed breakage of Shift-Ins paste.

I turned it into Shift-Return, because I was trying to find out why
the former didn't work on OS X and replaced it with something else
random to see if the code was even being reached. And then, like an
utter doofus, I committed that change as part of a50da0e30.

Ignore mouse events that didn't start with a click.

On OS X GTK, when you click in a pterm that wasn't the active window,
the first click activates it but is swallowed by the windowing system
- but a subsequent tiny drag can still be taken as part of a selection
action, making it difficult to activate the window in order to paste
into it.

Fixed by ignoring mouse drags when the terminal.c mouse state was
NO_SELECTION; if we've seen one prior click then it should be
ABOUT_TO, or DRAGGING if we saw a double or triple click.

Key rollover: fix the .htaccess files built by Buildscr.

The build script generates the .htaccess files that go in each
individual build and redirect generic names like 'putty.tar.gz' to the
real filenames including that build's version number. Those .htaccess
files redirect the corresponding signatures as well, so they need
updating now that we're generating signature files with a different
extension.

Key rollover: cut and paste errors in pgpkeys.but.

What should have been links to the old DSA keys were actually a second
copy of the links to the old RSA ones. Ahem.

Initial support for clipboard on OS X.

Rather than trying to get my existing hugely complicated X-style
clipboard code to somehow work with the Quartz GTK back end, I've
written an entirely new and much simpler alternative clipboard handler
usnig the higher-leve GtkClipboard interface. It assumes all clipboard
text can be converted to and from UTF-8 sensibly (which isn't a good
assumption on all front ends, but on OS X I think it's reasonable),
and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is
the only clipboard OS X has.

I had to do a fiddly thing to cope with the fact that each call to
gtk_clipboard_set_with_data caused a call to the clipboard clear
function left over from the previous set of data, so I had to avoid
mistaking that for a clipboard-clear for the _new_ data and
immediately deselecting it. I did that by allocating a distinct
placeholder object in memory for each instance of the copy operation,
so that I can tell whether a clipboard-clear is for the current copy
or a previous one.

This is only very basic support which demonstrates successful copying
and pasting is at least possible. For a sensible OS X implementation
we'll need a more believable means of generating a paste UI action
(it's quite easy to find a Mac on which neither Shift-Ins nor the
third mouse button even exists!). Also, after the trouble I had with
the clipboard-clear event, it's a bit annoying to find that it
_doesn't_ seem to get called when another application becomes the
clipboard owner. That may just be something we have to put up with, if
I can't find any reason why it's failing.

Fix assertion failure in xterm mouse tracking.

The original version of the xterm mouse tracking protocol did not
support character-cell coordinates greater than 223. If term_mouse()
got one, it would fail to construct an escape sequence for the mouse
event, and would then call ldisc_send() with a zero-length string -
which fails an assertion that I added in November (c269dd0135) on the
occasion of moving ldisc_echoedit_update() into its own function. So
the corresponding operation before that change would have done a
gratuitous ldisc_echoedit_update(), which is exactly the sort of thing
the assertion was there to catch :-)

Later extensions to the mouse tracking protocol support larger
coordinates anyway (try ESC[?1006h or ESC[?1015h in addition to the
ESC[?1000h that turns the whole system on in the first place). It's
only clients that don't use one of those extensions which would have
had the problem.

Thanks to Mirko Wolle for the report.

Key rollover: add a checklist item for the Download page.

Next time I do a release, I'll have to remember to adjust the download
page links to the GPG signature files.

Key rollover: put the new Master Key fingerprint in the tools.

For the moment we're also retaining the old ones. Not sure when will
be the best time to get rid of those; after the next release, perhaps?

Key rollover: switch to signing using the new keys.

sign.sh's command-line syntax has changed, so I've updated the sample
command line in CHECKLST as well. Also the file extensions of the
signatures have changed, so I've updated the pre-release verification
command line in CHECKLST too.

Key rollover: rewrite the PGP keys manual appendix.

This gives pride of place to the new set of keys we've recently
generated, and relegates the old ones to an afterthought.

OS X: fix handling of Ctrl-Space.

I'd left it out of my simulated Ctrl processing. It should have been
treated as \0, the same as ^2 and ^@.

Work around OS X GTK treating Option as an AltGr key.

If I'm using Option as the Meta key, I want to suppress OS X GTK's
default behaviour of treating it as an AltGr-oid which changes the
keyval and Unicode translation of alphabetic keys. So on OS X I enable
a somewhat bodgy workaround which retranslates from the hardware
keycode as if the Option modifier had not been active at the time, and
use that as the character to prefix Esc to.

This is a bit nasty because I have to hardwire group = 0 in the call
to gdk_keymap_translate_keyboard_state(), whereas in principle what I
wanted was group = (whatever would have resulted from everything else
in the key event other than MOD1). However, in practice, they seem to
be the same, so this will do for the moment.

On OS X, be able to configure either Option or Command as Meta.

Personally I like using Command as the Esc-prefixing Meta key in
terminal sessions, because it occupies the same physical keyboard
position as the Alt key that I'm used to using on non-Macs. OS X
Terminal uses Option for that purpose (freeing up Command for the
conventional Mac keyboard shortcuts, of course), so I anticipate
differences of opinion.

Hence, here's a pair of OSX-specific config options which permit a
user to set either, or neither, or both of those modifier keys to
function as the terminal Meta key.

pterm: move termios setup to after the fork.

On OS X, apparently, we can't do termios setup on the pty master, so
instead we have to leave it until we've opened the slave fd in the
child process. That works on Linux too, so let's leave it here rather
than having another cumbersome ifdef.

pterm: set IUTF8 on pty devices depending on charset.

In a UTF-8 pterm, it makes sense to set the IUTF8 flag (on systems
that have one) on the pty device, so that line editing will take
account of UTF-8 multibyte characters.

Work around Pango fonts with fractional width.

By retrieving characters' widths using get_extents and not
get_pixel_extents, we can spot when they're not actually an exact
multiple of a pixel, and avoid getting confused by the overall width
of a long string being off by up to a pixel per character.

Fix an uninitialised bufchain in NO_PTY_PRE_INIT mode.

The Pty that we created in pty_pre_init had its bufchain properly
initialised, but if that one didn't get created, then the one we
create in pty_init did not. Now both should go through the same init
routine.

Slightly improve layout in GTK3 Pageant passphrase prompts.

Now I've moved align_label_left() into gtkmisc.c where gtkask.c can
get at it, we can use it to fix the alignment of the prompt label.
Also, use gtk_label_set_width_chars() to give the label a more or less
sensible width.

Move more functions into the new gtkmisc.c.

Several utility functions I've written over the last few weeks were in
rather random places because I didn't have a central gtkmisc.c to put
them in. Now I've got one, put them there!

Stop using GtkDialog (for most purposes) in GTK 3!

They've now deprecated gtk_dialog_get_action_area, because they really
want a dialog box's action area to be filled with nothing but buttons
controlled by GTK which end the dialog with a response code. But we're
accustomed to putting all sorts of other things in our action area -
non-buttons, buttons that don't end the dialog, and sub-widgets that
do layout - and so I think it's no longer sensible to be trying to
coerce our use cases into GtkDialog.

Hence, I'm introducing a set of wrapper functions which equivocate
between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in
it for GTK3, and I'll lay out the action area by hand.

(Not everything has sensible layout and margins in the new GTK3 system
yet, but I can sort that out later.)

Because the new functions are needed by gtkask.c, which doesn't link
against gtkdlg.c or include putty.h, I've put them in a new source
file and header file pair gtkmisc.[ch] which is common to gtkask and
the main GTK edifice.

Add a missing cast in g_object_set.

When NULL appears in variadic argument lists, it should be cast to the
pointer type that the function will be expecting, because otherwise it
might end up as a type not even the same size as a pointer.

Use GtkMessageDialog for dlg_error().

This is a much simpler way to display simple message-box type dialogs,
whose absence I've previously been working around by laboriously
constructing something in my usual style.

Stop using GtkAlignment in GTK 3.

We were using it in the main config box to ensure everything expanded
on window resize, but in GTK3 that's the default anyway. And we were
using it to put padding around the edges of the font selector, which
is now done using the "margin" property.

Avoid deprecated gtk_misc_set_alignment().

As of GTK 3.16 (but not in previous GTK 3 versions), there's a new
gtk_label_set_xalign which does this job.

Avoid using gdk_cursor_new() in GTK 3.

It's deprecated in up-to-date versions, but fortunately, the
workaround is just to explicitly include the appropriate GdkDisplay.

Switch to gdk_rgba_parse() for GDK 3.

I'm using a slightly more up-to-date GTK version for testing on MacOS,
and it's marked a few more functions as deprecated, among which is
gdk_color_parse(). So now parsing -fg and -bg options has to be done
by two different calls and an ugly #ifdef, depending on GTK version.

Don't use "server:fixed" as the default font without X.

If we're not supporting server-side fonts, it's utterly silly to set
one as the default! Instead, we use Pango's guarantee that some
reasonably sensible monospaced font will be made available under the
name "Monospace", and use that at a reasonable default size of 12pt.

Introduce a config option for building on OS X GTK.

Using GTK to run on OS X is going to require several workarounds and
behaviour tweaks to be enabled at various points in the code, and it's
already getting cumbersome to remember what they all are to put on the
command line. Here's a central #define (OSX_GTK) that enables them all
in one go, and a configure option (--with-quartz) that sets it.

As part of this commit, I've also rearranged the #include order in the
GTK source files, so that they include unix.h (which now might be
where NOT_X_WINDOWS gets defined) before they test NOT_X_WINDOWS to
decide whether to include X11 headers.

Handle the Ctrl modifier key ourselves if necessary.

The Quartz GDK back end, if you press (say) Ctrl-A, will generate a
GdkKeyEvent with keyval='a' and state=CONTROL, but it'll have a
translated string of "a" where the X back end would have returned
"\001". So we have to do our own translation, which fortunately isn't
hard.

Add a bodge to make pty masters nonblocking on OS X.

OS X for some reason doesn't let my usual fcntl approach (wrapped in
nonblock()) work on pty masters - the fcntl(F_SETFL) fails, with the
(in this context) hilariously inappropriate error code ENOTTY. Work
around it by instead passing O_NONBLOCK to posix_openpt.

Add a new #define to disable pty_pre_init.

OS X dislikes us calling the setuid or setgid syscalls when not
privileged, even if we try to set ourselves to the _same_ uid/gid.
Since I don't anticipate this code needing to run setuid on OS X, and
since I do anticipate wanting to handle multiple ptys in a single
process so that pty_pre_init would be useless anyway, the simplest fix
seems to me to be just conditioning out the whole of pty_pre_init
completely.

Remove LIBS from Unix pageant Recipe line

The Recipe line for Unix pageant mistakenly included LIBS which is
the set of Windows standard libraries.  Remove it.

Make Columns disregard the preferred width of GtkEntry.

On OS X GTK, it requests a preferred width that's way too large. I
think that's because that's based on its max_width_chars rather than
its width_chars (and I only set the latter). But I don't want to
actually reduce its max_width_chars, in case (either now or in a
future version) that causes it to actually refuse to take up all the
space it's allocated.

Stop using abs(unsigned) in X11 time comparison.

The validation end of XDM-AUTHORIZATION-1 needs to check that two
time_t values differ by at most XDM_MAXSKEW, which it was doing by
subtracting them and passing the result to abs(). This provoked a
warning from OS X's clang, on the reasonable enough basis that the
value passed to abs was unsigned.

Fixed by using the (well defined) unsigned arithmetic wraparound: to
check that the mathematical difference of two unsigned numbers is in
the interval [-k,+k], compute their difference _plus k_ as an
unsigned, and check the result is in the interval [0,2k] by doing an
unsigned comparison against 2k.

Add conditioned-out diagnostics in GTK key_event().

These should dump out all the important parts of the incoming
GdkEventKey, so that if keys aren't being translated right, it should
be possible to work out something about why not.

To enable: make CPPFLAGS="-DKEY_EVENT_DIAGNOSTICS"

Add conditioned-out diagnostics in columns_compute_width.

These are a slightly cleaned-up version of the diagnostics I was using
to debug the layout problems in the GTK3 config box the other day. In
particular, if the box comes out far too wide - as I've just found out
that it also does when I compile the current state of the code against
OS X GTK3 - these diagnostics should provide enough information to
figure out which control is the limiting factor.

To enable: make CPPFLAGS="-DCOLUMNS_WIDTH_DIAGNOSTICS"

Turn GTK3 deprecation warnings back on.

After the last few commits, we now compile cleanly against GTK3 even
without -Wno-deprecated-declarations, so let's turn the default
warnings back on to ensure we don't regress that.

Remove a mysterious GTK size-request tweak.

In shortcut_add(), when we add an underlined letter to a GtkLabel, we
were fetching the label's height before changing its text, and
restoring it afterwards. I've no idea why - I can see no difference
with and without the code.

That code's been there since 2003 without explanation. My best guess
is that it was working around a GTK bug of the day, but since no
difference is visible even in current GTK1, I think I'm just going to
remove it. If any problems show up later, I can put it back, with an
actual comment!

Compile fixes for GTK1 after recent work.

The whole of get_label_text_dimensions() should have been outside the
GTK 2 ifdef; I'd left a gtk_label_set_width_chars() unconditional; and
GDK1's gdk_window_set_background() lacks a const in its prototype.
Serves me right for not test-compiling in all three versions!

Fix the config box treeview width in GTK3.

My trickery in GTK2 to start with some branches of the tree collapsed
but give the widget all the width it will need when they open later
was not working in GTK3, for the same reason I've needed several other
fixes recently: just after creation, GTK3 widgets report their
preferred size as zero.

Fixed by doing basically the same trick I was doing in GTK2, but
deferring it until the "map" event happens later on.

Make string_width() work in GTK3.

This was another piece of code that determined text size by
instantiating a GtkLabel and asking for its size, which I had to fix
in gtkfont.c recently because that strategy doesn't work in GTK3.

Replaced the implementation of string_width() with a call to the
function I added in gtkfont.c, and now dialog boxes which depend on
that for their width measurement (e.g. the one in reallyclose()) don't
come out in silly sizes on GTK3 any more.

Use columns_force_same_height() for vertical centring.

In cases where two controls sit alongside one another such as a label
alongside an edit box, I've previously been arranging for them to be
vertically centred by fiddling with the size request and alignment of
what I assume will be the shorter control. But now I've written
columns_force_same_height(), that's a much easier approach, and it's
also compatible with GTK3 without using a deprecated method; so this
change switches over all vertical centring to doing it that way.

Also, while I'm here, I noticed that the edit box and button of
CTRL_FILESELECT / CTRL_FONTSELECT were not vertically centred, and
since it's now really easy to make sure they are, I've added another
use of columns_force_same_height() there.

New Columns method, columns_force_same_height().

This forces two child widgets of a Columns to occupy the same amount
of vertical space, and if one is really shorter than the other,
vertically centres it in the extra space.

Factor out columns_find_child() in the Columns class.

This is an obviously reusable loop over cols->children looking for a
widget, which I'm about to use a couple more times so it seems worth
pulling it out into its own helper function.

Another GTK3 fix for GtkEntry width.

When I committed 5e738877b the other day, I missed another case of the
same thing in the file/font selector handling.

Use new GTK3 API call for server-controlled window resize.

gtk_window_resize_to_geometry() allows us to make use of the already-
set-up WM resize hints to immediately figure out how to resize the
window to a particular character cell size, and hence makes a much
simpler implementation of request_resize() than the previous hackery.

In GTK3, omit our GTK 1/2 workaround for wrapping labels.

Now we're properly implementing the GTK3 height-for-width layout
model, this bodge is no longer necessary.

Implement GTK3 height-for-width layout in Columns.

Now that I've got the main calculation code separated from the GTK2
size_request and size_allocate top-level methods, I can introduce a
completely different set of GTK3 top-level methods, which run the same
underlying calculations but based on different width and height
information.

So now we do proper height-for-width layout, as you can see if you
flip the PuTTY config box to a pane with a wrapping label on it (e.g.
Fonts or Logging) and resize the window horizontally. Where the GTK2
config box just left the wrapped text label at its original size, and
the GTK3 one before this change would reflow the text but without
changing the label's height, now the text reflows and the controls
below it move up and down when the number of lines of wrapped text
changes.

(As far as I'm concerned, that's a nice demo of GTK3's new abilities
but not a critically important UI feature for this app. The more
important point is that switching to the modern layout model removes
one of the remaining uses of the deprecated gtk_widget_size_request.)

GTK3 prep: refactor the layout calculation in Columns.

Previously, columns_size_request and columns_size_allocate would each
loop over all the widgets doing computations for both width and
height. Now I've separated out the width parts from the height parts,
and moved both out into four new functions, so that the top-level
columns_size_request and columns_size_allocate are just wrappers that
call the new functions and plumb size and position information between
them and GTK.

Actual functionality should be unchanged by this patch.

Performance: cache character widths returned from Pango.

Profiling reveals that pterm in Pango rendering mode uses an absurd
amount of CPU when it's not even actually _drawing_ the text, because
of all the calls to pango_layout_get_pixel_extents() while
pangofont_draw_text tries to work out which characters it can safely
draw as part of a long string. Caching the results speeds things up
greatly.

Fix an arithmetic error in the X font downloader cache.

If you're trying to arrange that an array size is large enough for
element n to exist, and you also want to round it up to the next
multiple of 0x100, you must set the size to (n + 0x100) & ~0xFF, and
not (n + 0xFF) & ~0xFF. Put another way, the number you have to round
up is not n, but the minimum size n+1 that causes array[n] to exist.

'pterm --display' should set $DISPLAY inside the terminal.

If you open a pterm on a different display via the --display
command-line option rather than by setting $DISPLAY, I think (and
other terminals seem to agree) that it's sensible to set $DISPLAY
anyway for processes running inside the terminal.

In GTK3, use the new GtkColorChooserDialog.

This replaces the old GtkColorSelectionDialog, and has the convenience
advantage that the actual chooser (with all the 'set colour', 'get
colour' methods) and the containing dialog box are now the same object
implementing multiple interfaces, so I don't keep having to call 'get
me the underlying chooser for this dialog' accessors. Also you now
hook into both the OK and Cancel buttons (and all other response
codes) at the same time with a single event.

In GTK3, unifontsel should use GtkGrid, not GtkTable.

GtkTable is deprecated; the way of the future is GtkGrid, in which you
don't have to specify the number of rows/columns in advance (it's
worked out dynamically by observing what row/column numbers you
actually attached anything to), and also you handle expansion
behaviour by setting the "hexpand", "vexpand" or "expand" properties
on the child widgets rather than setting flags in the container.

Stop using GTK3-deprecated gdk_window_set_background().

We now have to use gdk_window_set_background_rgba(), having first set
up an appropriate GdkRGBA structure.

Stop using GTK3-deprecated gdk_get_display().

The new way is gdk_display_get_name(gdk_display_get_default()), which
returns a const char * rather than a char *, so I've also had to
fiddle with the prototype and call sites of get_x_display().

(Also included gtkcompat.h into uxputty.c, since that wanted to call
gdk_get_display() but didn't previously include it.)

Provide #defines for GTK3-deprecated gtk_{h,v}foo_new().

In GTK3, GtkBox, GtkScrollbar and GtkSeparator are all single classes
with a GtkOrientation parameter, whereas in GTK2 the horizontal and
vertical versions were trivial subclasses of them. Hence, the old
constructors are now deprecated, but _only_ the constructors are
affected, since after constructing one you always used methods of the
superclass on it anyway.

Rather than faff about with an ifdef at every call site, I've just put
some wrapper macros in gtkcompat.h to make it easy to keep this code
similar between all supported GTK versions.

Avoid deprecated gtk_cell_renderer_get_size in GTK3.

gtk_cell_renderer_get_preferred_size() is the new way to do it.

Stop using deprecated GTK_STOCK_* in GTK3.

According to the GTK3 docs, we're now supposed to use fixed label
strings instead.

Make unifontsel_deselect() clear the preview pane.

In the case where we deselect the previously selected font (e.g.
because we've just changed the filter settings to remove it from the
list), we were leaving the preview pane in its previous state, which
is fine in GTK2 when it just carries on displaying the last thing
drawn to the backing pixmap but goes wrong in GTK3 where we still have
to actually respond to draw events.

But it makes more conceptual sense anyway to actually empty the
preview pane when no font is selected, so now we do that. So now
unifontsel_draw_preview_text() is called from unifontsel_deselect(),
and also the preview-drawing code will still draw the background
rectangle regardless of whether font != NULL.

Fix crash in GTK3 when unifontsel filter settings change.

The call to gtk_list_store_clear() in unifontsel_setup_familylist()
was causing a call to family_changed() via the GTK signal system,
which didn't happen in GTK2. family_changed() in turn was calling
unifontsel_select_font(), which got confused when the tree model
didn't match reality, and tried to access a bogus tree iterator.

This is easily fixed by using the existing fs->inhibit_response flag,
which prevents us responding to GTK events when we know they were
generated by our own fiddling about with the data; it's just that we
never needed to set it in unifontsel_setup_familylist() before.

Also, added a check of the return value from the key get_iter call in
unifontsel_select_font(), so that it'll at least fail an assertion
rather than actually trying to access bogus memory. But that operation
_should_ still always succeed, and if it doesn't, it's probably a sign
that we need another use of fs->inhibit_response.

Fix GTK3 size calculations in unifontsel_new.

It turns out that in GTK3, if you instantiate a GtkLabel and
immediately try to find out its preferred size, you get back zero for
both dimensions. Presumably none of that gets figured out properly
until the widget is displayed, or some such.

However, you can retrieve the PangoLayout from the label immediately
and ask Pango for the dimensions of that. That seems like a bit of a
bodge, but it works! The GTK3 unifont selector now comes out with all
the interface elements in sensible sizes - in particular, the preview
drawing area now has non-zero height.

In GTK3, don't use the "has-separator" GtkDialog property.

It doesn't exist any more, so the attempt to set it was generating an
annoying runtime warning message.

Use GTK3's method of setting GtkEntry min width.

The config box setup code wants a lot of very narrow edit boxes, so it
decreases their minimum width from the GTK default of 150 pixels. In
GTK 3, we have to do this using gtk_entry_set_width_chars() rather
than gtk_widget_set_size_request() as we were previously using, or it
won't work.

This change by itself seems to restore the GTK3 config box to a
sensible layout, in spite of the fact that my Columns layout class is
still doing all its size allocation the GTK2 way, with no attention
paid to the shiny new GTK3 height-for-width system.

Remove arbitrary limit SSH2_MKKEY_ITERS.

Tim Kosse points out that we now support some combinations of crypto
primitives which break the hardwired assumption that two blocks of
hash output from the session-key derivation algorithm are sufficient
to key every cipher and MAC in the system.

So now ssh2_mkkey is given the desired key length, and performs as
many iterations as necessary.

Add a key-length field to 'struct ssh_mac'.

The key derivation code has been assuming (though non-critically, as
it happens) that the size of the MAC output is the same as the size of
the MAC key. That isn't even a good assumption for the HMAC family,
due to HMAC-SHA1-96 and also the bug-compatible versions of HMAC-SHA1
that only use 16 bytes of key material; so now we have an explicit
key-length field separate from the MAC-length field.

Add copy and free methods to 'struct ssh_hash'.

This permits a hash state to be cloned in the middle of being used, so
that multiple strings with the same prefix can be hashed without
having to repeat all the computation over the prefix.

Having done that, we'll also sometimes need to free a hash state that
we aren't generating actual hash output from, so we need a free method
as well.

New test output file, checking all display-relevant stuff.

This is the test file I wish I'd had while I was rewriting the
text-drawing function this week :-) Better late than never.

GTK3 port: add '--with-gtk=3' to the configure script.

After the last few changes, the whole codebase now compiles and links
successfully against GTK3, and I can run an experimental pterm. The
config box and font selector look ugly, but the basics all seem to
work.

In order to compile at all, I had to manually bodge in the extra
compile flag -Wno-deprecated-declarations. My plan is to fix all the
uses of deprecated things, and then remove that flag.

I've made GTK3 the second choice, after GTK2 but before GTK1. GTK2 is
the only GTK version that produces a completely sensible build (partly
because the GTK3 port is visibly unfinished, and mostly because its
server-side font handling is just too slow), so it remains the first
choice.

GTK3 port: condition out all uses of GdkColormap.

The entire concept has gone away in GTK3, which assumes that everyone
is now using modern true-colour video modes and so there's no longer
any reason you shouldn't just casually make up any RGB triple you like
without bothering to ask the display system's permission.

GTK3 port: respell GDK_WINDOW_XWINDOW / GDK_DRAWABLE_XID.

GDK3 now spells both of those as GDK_WINDOW_XID. (Of course 'drawable'
is no longer a relevant concept in GDK3, since pixmaps are no longer
supported and so all drawables are just windows.) We keep backwards
compatibility, of course.

GTK3 port: replace size_request in the Columns layout class.

It's been replaced by a new pair of methods get_preferred_width and
get_preferred_height. For the moment, I've followed the porting
guide's suggestion of keeping the old size_request function as an
underlying implementation and having each of those methods just return
one of its outputs. The results are ugly, but it'll compile and run,
which is a start.

GTK3 port: use gdk_device_grab() in gtkask.c.

This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has
to use for grabbing the keyboard away from all other X clients.

GTK3 port: support the new "draw" signal.

This replaces GTK 1/2's "expose_event", and provides a ready-made
cairo_t to do the drawing with. My previous work has already separated
all constructions of a cairo_t from the subsequent drawing with it, so
the new draw event handlers just have to call the latter without the
former.

Reimplement GTK uxsel_input_add using GIOChannel.

This is the new recommended approach since gdk_input_{add,remove} were
deprecated (and, honestly, seems a lot more sensible - why on earth
would those functions have lived in *GDK* of all places?). The old
implementation is preserved under ifdef for GTK1.

This was the last of the GDK deprecated functions to go! So GTK PuTTY
now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all
the other precautionary flags (though if you do that, you disable GDK
rendering, which greatly slows down server-side font handling). This
completes the GTK2-compatible preparation phase of the GTK 3 migration
guide.

Change uxsel_input_add's return type from int to pointer.

In case a front end needs to store more than an integer id to be
returned to uxsel_input_remove, we now return a pointer to a
frontend-defined structure.

Use gtk_window_set_icon() where available.

GTK is deprecating the use of gdk_window_set_icon(), in favour of a
method that doesn't have to drop down to the GDK level at all (and
also doesn't use a pixmap). No reason not to use that instead.

Remove an outdated comment.

I've just noticed the comment in gtkfont.c that said wouldn't it be
nice to find a way to avoid the GDK pixmap-stretching code when using
Pango fonts. We now do support this, but we support it in gtkwin.c
rather than gtkfont.c - because we do it using a Cairo transformation
matrix, so it still takes place at the level above Pango rather than
in Pango proper. (I never did find out whether Pango itself included
facilities to arbitrarily stretch a font.)

Hence, this comment is useless now. Discard.

Replace deprecated GDK_DISPLAY() with modern facilities.

We still don't actually support more than one X display active at
once, so it's sufficient to replace every call to that macro with
GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).

Make the use of server-side backing pixmaps in GTK optional.

We won't be able to use them in GTK3, or when compiling with GTK2 and
-DGDK_DISABLE_DEPRECATED.

This applies to the one we use for the main terminal window, and also
the small one we use for the preview pane in the unified font selector.

Saw unifontsel_draw_preview_text() in half.

Now it's got an inner half that does actual drawing given a draw
context, and an outer half that sets up and tears down the draw
context. Sooner or later the inner half will need calling
independently of the outer, because GTK3's draw event will provide a
ready-made cairo_t.

Call draw_stretch_before *after* setting up the clip region.

A small bug in yesterday's work: since in Cairo mode
draw_stretch_before changes the transformation matrix, if we do it
before calling draw_clip then the clip region will be interpreted in
the transformed coordinates.

This caused a subtle display bug in yesterday's commit: drawing one
half of double-height text would have drawn _both_ halves of it on to
the window's backing pixmap, but only copied the correct half on to
the window proper - but the overdrawing on the pixmap would have shown
up if the window was hidden and re-exposed.

Withdraw the horrible bodge in make_mouse_ptr().

We were previously building our own mouse pointers out of pixmaps,
having first drawn characters from the X server standard font 'cursor'
on to those pixmaps, giving an effect almost exactly the same as just
calling gdk_cursor_new(some constant) except that we got to choose the
foreground and background colours of the resulting pointers.

But it's not clear why we needed to do that! In both GTK1 and GTK2 as
of my current testing, the standard colours appear to be just what I
wanted anyway (white pointer with black outline). The previous
implementation (and commit comment) was written in 2002, so perhaps it
was working around a GTK1 bug of the time.

So I've removed it completely, and replaced it with simple calls to
gdk_cursor_new  (plus a workaround for GTK1's lack of GDK_BLANK_CURSOR,
but that's still much simpler than the previous code). If anyone does
report a colour problem, I may have to go back to doing something
clever, but if I can possibly arrange it, I'll want to do it by some
other technique, probably (as suggested in a comment in the previous
implementation) getting the underlying X cursor id and calling
XRecolorCursor.