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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
