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()).
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.
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.
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.
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.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
I was tacitly assuming that mfont->fallback would always be non-NULL,
which is true in a world containing Pango, but untrue in GTK1 when
Pango isn't there. In that situation we fall back to just omitting the
characters that would be displayed in the fallback font, on the
grounds that that's better than dereferencing through a NULL vtable.
We are passing pointers as third argument to AppendMenu. Do not
truncate them to UINT, use UINT_PTR instead which has the required
size on 64bit Windows.
We're passing a pointer as 4th argument to WinHelp. Do not cast it to
DWORD which would truncate the pointer. Instead use UINT_PTR as that
is what WinHelp expects.
The aim is to try to reduce the incidence of the two least helpful
classes of those reports: the ones which have just got mismatched
checksum files, and the ones which don't tell us the information that
would help.
GTK 2 has deprecated it and provided no replacement; a bug tracker
entry I found on the subject suggested that it was functionality that
didn't really belong in GTK, and glib ought to provide a replacement
instead, which would be a perfectly fine thing to suggest if they had
waited for glib to get round to doing so *before* throwing out a
function people were actually using. Sigh.
Anyway, it turns out that subsidiary invocations of gtk_main() don't
happen inside GTK as far as I can see, so all I need to do is to make
sure my own invocations of gtk_main() are followed by a cleanup
function which runs any quit functions that I've registered.
That was the last deprecated GTK function, so we now build cleanly
with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits
ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that
has migrating to Cairo drawing as a prerequisite.)
Now that I've got a general place to centralise handling of at least
the simple differences between GTK 1 and 2, I should use it wherever
possible. So this commit removes just a small number of ifdefs which
are either obsoleted by definitions already in gtkcompat.h (like
set_size_request vs set_usize), or can easily be replaced by adding
another (e.g. gtk_color_selection_set_has_opacity_control).
Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile
failure, for the use of gtk_quit_add() in idle_toplevel_callback_func.
That function is apparently removed with no replacement in GTK 3, so
I'll need to find a completely different approach to getting toplevel
callbacks to run only in the outermost instance of gtk_main().
Also, this change doesn't do anything about the use of *GDK*
deprecated functions, because those include the entire family of
old-style drawing functions - i.e. the only way to build cleanly with
-DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
On GTK versions where it's available, this is a much nicer way of
handling the -geometry command-line option, since not only do we get
all the faffing about with gravity for free, it also automatically
sets the user-position WM hints.
I've put in a special #define to control this selection, in case I
decide that for reasons of taste I'd prefer to switch back to
GtkFileSelection in GTK2 which supports both!
Replaces the deprecated gtk_color_selection_set_color() which took an
array of four doubles (RGBA), and instead takes a 'GdkColor' struct
containing four 16-bit integers.
For GTK1, we still have to retain the original version.
All the things like GtkType, GtkObject, gtk_signal_connect and so on
should now consistently have the new-style glib names like GType,
GObject, g_signal_connect, etc.
A major aim of introducing GTK 3 support is to permit compiling for
non-X11 platforms that GTK 3 supports, so I'm going to need to be able
to build as a pure GTK application with no use of X11 internals.
Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode
in which X server-side bitmap fonts are available.
Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's
the same compatibility flag that was already used by the unfinished OS
X port to disable the X-specific parts of uxpty.c; now it just applies
to more source files.
(There's no 'configure' option to set this flag at present. I haven't
worked out whether we'll need one yet.)
GTK 2 doesn't _documentedly_ provide a helpful compile option to let
us check this one in advance of GTK 3, but you can fake one anyway by
compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h
will believe that it's already been included :-) We now build cleanly
under GTK 2 with that predefine.
This is the first of several cleanup steps recommended by the GTK 2->3
migration guide.
I intend to begin work towards compatibility with GTK 3, but without
breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is
still useful to _me_ (not least because it permits much easier support
of old-style server-side X11 fonts), and I recall hearing a rumour
that at least one kind of strange system can only run GTK 1, so for
the moment I don't intend to stop supporting either.
Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does
not include it. In GTK 3 it does, so we don't explicitly reinclude it
ourselves.
We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But
that doesn't say much, because we did already! Apparently gdkkeysyms.h
was a special case which that #define didn't forbid.)
This is less than ideal - passphrase input now happens in ISO 8859-1,
and the passphrase prompt window is neither centred nor always-on-top.
But it basically works, and restores bare-minimum GTK 1 support to the
codebase as a whole.
Users have requested this from time to time, for distinguishing log
file names when there's more than one SSH server running on different
ports of the same host. Since we do take account of that possibility
in other areas (e.g. we cache host keys indexed by (host,port) rather
than just host), it doesn't seem unreasonable to do so here too.
We've had several reports that launching saved sessions from the
Windows 10 jump list fails; Changyu Li reports that this is because we
create those IShellLink objects with a command line string starting
with @, and in Windows 10 that causes the SetArguments method to
silently do the wrong thing.
If a PuTTY SSH packet log has gone through line-wrapping at 72
columns, destroying the long lines of the packet hex dumps, then this
script will reconstitute it as best it can, by reconstructing the
ASCII section at the end of the dump from the (hopefully) undamaged
hex part, and using that to spot wrapped lines and remove the
subsequent debris.
A user reports that in a particular situation one of the calls to
LoadLibrary from wingss.c has unwanted side effects, and points out
that this happens even when the saved session has GSSAPI disabled. So
I've evaluated as much as possible of the condition under which we
check the results of GSS library loading, and deferred the library
loading itself until after that condition says we even care about the
results.
If you're counting up to ms_limit in steps of ms_step, it's silly to
add ms_step at the end of the loop body _and_ increment the loop
variable by 1 in the loop header. I must have been half asleep.
This is generated in response to the SendInput() Windows API call, if
that in turn is passed an KEYBDINPUT structure with KEYEVENTF_UNICODE
set. That method of input generation is used by programs such as
'WinCompose' to send an arbitrary Unicode character as if it had been
typed at the keyboard, even if the keyboard doesn't actually provide a
key for it.
Like VK_PROCESSKEY, this key code is an exception to our usual policy
of manually translating keystrokes: we handle it by calling
TranslateMessage, to get back the Unicode character it contains as a
WM_CHAR message.
(If that Unicode character in turn is outside the BMP, it may come
back as a pair of WM_CHARs in succession containing UTF-16 surrogates;
if so, that's OK, because the new Unicode WM_CHAR handler can cope.)
This causes WM_CHAR messages sent to us to have a wParam containing a
16-bit value encoded in UTF-16, rather than an 8-bit value encoded in
the system code page.
As far as I can tell, there aren't many other knock-on effects - e.g.
you can still interact with the window using ordinary char-based API
functions such as SetWindowText, and the Windows API will do the
necessary conversions behind the scenes. However, even so, I'm half
expecting some sort of unforeseen bug to show up as a result of this.
