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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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"
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"
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.
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!
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!
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.)
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.
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.
Simon Tatham
Owen S. Dunn