This should avoid the possibility of the SIGWINCH handler's blocking
when trying to write to the pipe. This could only happen if we'd
somehow received PIPE_BUF SIGWINCHes without reading the pipe, which
would be difficult to achieve.
While we're at it, also set O_NONBLOCK on the reading side of the pipe,
just in case.
A side effect of commit 1f9df706b seems to have been to squash those
areas right up against the bottom of the dialog box, which is ugly. I
don't fully understand why it only happens to those drawing areas and
not to buttons placed in the fake 'action area' by other dialogs, but
anyway, adding an explicit margin-bottom attribute seems to solve it.
This is another widget that can appear in the top-level window, in
addition to the drawing area and scrollbar we put there ourselves, and
hence which needs to be accounted for when figuring out the
relationship between the drawing area size in character cells and the
full window size in pixels.
Finding the menu bar widget itself is a bit of a hassle, but having
found it, dealing with it is basically the same as dealing with the
scrollbar, only with x and y swapped.
This function, which parses the X11-style '-geometry WxH+X+Y' option
argument and automatically loads the result into the window, is also
being deprecated.
Fortunately we already had a fallback option for GTK1 (which didn't
have gtk_window_parse_geometry in the first place), calling the Xlib
geometry-parsing function and manually loading the results into GTK.
The method of loading into GTK is not the same between the two
versions, but the basic strategy is still viable.
For the sake of maintaining and testing fewer ifdef branches, I've
removed the use of gtk_window_parse_geometry _completely_, even in
GTK2 which did have it. GTK2 now uses the same strategy that I've
switched to for GTK3.
gtk_window_resize_to_geometry and gtk_window_set_default_geometry are
deprecated as of GTK 3.20, so now we do the geometry -> pixel size
conversion on our side.
This is preparation for dealing with the fact that GTK's geometry-
based API routines for setting the window size are being deprecated:
we'll no longer be able to specify a width/height in characters and
have GTK convert that into a pixel size based on the geometry hints
we'd already fed it. So we'll need to do that conversion ourselves,
and the easiest approach is to make it easy to recompute the geometry
hints on our side whenever we need them.
gdk_device_grab and all its preparatory faff are now deprecated, and
gdk_seat_grab is the new thing. Introduce yet another branch to all
the ifdefs for keyboard-grabbing. On the plus side, at least it's
slightly simpler than the GdkDevice business.
That function is deprecated as of 3.18, on the basis that GTK doesn't
need telling any more when the adjustment's owning widget needs
updating. So we just need to condition out the call.
Protecting our processes from outside interference need not be limited
to just PuTTY: there's no reason why the other SSH-speaking tools
shouldn't have the same treatment (PSFTP, PSCP, Plink), and PuTTYgen
and Pageant which handle private key material.
E.g. you might pass '--random-device=/dev/urandom'.
Mostly because I got sick of waiting for /dev/random to finish
blocking while I was trying to generate throwaway keys for testing bug
fixes in cmdgen itself. But it might also be useful on systems that
call their random device by a different name that we haven't
encountered.
(Since cmdgen also reads the saved PuTTY random seed file, setting
this option to /dev/zero will not render key generation deterministic.
It's tempting to provide _some_ way to do that, for testing purposes
and clearly marked as dangerous of course, but I think it would take
more faff than this.)
Partly this is because the geometry_widget functionality is going away
in a later version of GTK3, so sooner or later we'll need not to be
using it anyway. But also, it turns out that GTK 3's geometry
calculations have the unfortunate effect of setting the window's base
and min heights to values that are not congruent mod height_increment
(because the former is the value we gave, but the latter is based on
the minimum height of the scrollbar), which confuses at least one
window manager (xfwm4) and causes the window to be created one row too
small.
So I've redone all the geometry computations my own way, based on the
knowledge that the only widgets visible in the top-level window are
the drawing area and the scrollbar and I know how both of those
behave, and taking care to keep base_height and min_height congruent
to avoid that xfwm4 bug.
If you're connecting to a new server and it _only_ provides host key
types you've configured to be below the warning threshold, it's OK to
give the standard askalg() message. But if you've newly demoted a host
key type and now reconnect to some server for which that type was the
best key you had cached, the askalg() wording isn't really appropriate
(it's not that the key we've settled on is the first type _supported
by the server_, it's that it's the first type _cached by us_), and
also it's potentially helpful to list the better algorithms so that
the user can pick one to cross-certify.
It won't return true, because pterm's use of conf is a bit nonstandard
(it doesn't really bother about the protocol field, and has no use for
either host names _or_ serial port filenames). Was affecting both
gtkapp and gtkmain based builds.
The About box is where it showed up most obviously that I'd hastily
bunged a GtkBox inside another GtkBox without considering their
margins: the 'action area' had twice the margin it should have had and
the rightmost button didn't align with the right edge of the rest of
the window contents.
Easily fixed by giving the inner hbox margin 0 (fixing the right align
and the excessive space around all the buttons), and using the
'spacing' property of GtkBox to ensure multiple buttons in it are
nicely separated without having to take care over that in the client
code that adds them.
This commit adds two .plist files, which go in the app bundles; two
.bundle files, which are input to gtk-mac-bundler and explain to it
how to _create_ the bundles; and a piece of manual addition to
Makefile.am that actually runs gtk-mac-bundler after building the
gtkapp.c based binaries and the OSX launcher. The latter is
conditionalised on configuring --with-quartz (unlike the binaries
themselves, which you can build on other platforms too, though they
won't do much that's useful).
The big problem with making an OS X application out of a GTK program
is that it won't start unless DYLD_LIBRARY_PATH and several other
environment variables point at all the GTK machinery. So your app
bundle has to contain two programs: a launcher to set up that
environment, and then the real main program that the launcher execs
once it's done so.
But in our case, we also need pterm to start subprocesses _without_
all that stuff in the environment - so our launcher has to be more
complicated than the usual one, because it's also got to save every
detail of how the environment was when it started up. So this is the
launcher program I'm going to use. Comments in the header explain in
more detail how it'll work.
Also in this commit, I add the other end of the same machinery to
gtkapp.c and uxpty.c: the former catches an extra command-line
argument that the launcher used to indicate how it had munged the
environment, and stores it in a global variable where the latter can
pick it up after fork() and use to actually undo the munging.
When it's finished, this will be the backbone of the OS X GTK port:
using a GtkApplication automatically gives us a properly OS X
integrated menu bar.
Using this source file in place of gtkmain.c turns the usual Unix
single-session-per-process PuTTY or pterm into the multi-session-per-
process OS X style one.
Things like Duplicate Session can be done much more simply here - we
just grab the Conf * from the source window and launch a new window
using it, with no fiddly interprocess work needed.
This is still experimental and has a lot of holes, but it's usable
enough to test and improve.
This is a weird thing to have to do, but it is necessary: the OS X
PuTTY will need its top-level windows to be instances of a thing
called GtkApplicationWindow, rather than plain GtkWindow. Hence, the
actual creation of windows needs to be somewhere that isn't
centralised between the two kinds of front end.
Instead of main() living in uxputty.c and uxpterm.c, and doing a
little bit of setup before calling the larger pt_main() in gtkmain.c,
I've now turned things backwards: the big function in gtkmain.c *is*
main(), and the small pieces of preliminary setup in uxputty.c and
uxpterm.c are now a function called setup() which is called from
there. This will allow me to reuse the rest of ux{putty,pterm}.c, i.e.
the assorted top-level bits and pieces that distinguish PuTTY from
pterm, in the upcoming OS X application that will have its own main().
This lays further groundwork for the OS X GTK3 port, which is going to
have to deal with multiple sessions sharing the same process. gtkwin.c
was a bit too monolithic for this, since it included some
process-global runtime state (timers, toplevel callbacks), some
process startup stuff (gtk_init, gtk_main, argv processing) and some
per-session-window stuff.
The per-session stuff remains in gtkwin.c, with the top-level function
now being new_session_window() taking a Conf. The new gtkmain.c
contains the outer skeleton of pt_main(), handling argv processing and
one-off startup stuff like setlocale; and the new gtkcomm.c contains
the pieces of PuTTY infrastructure like timers and uxsel that are
shared between multiple sessions rather than reinstantiated per
session, which have been rewritten to use global variables rather than
fields in 'inst' (since it's now clear to me that they'll have to
apply to all the insts in existence at once).
There are still some lurking assumptions of one-session-per-process,
e.g. the use of gtk_main_quit when a session finishes, and the fact
that the config box insists on running as a separate invocation of
gtk_main so that one session's preliminary config box can't coexist
with another session already active. But this should make it possible
to at least write an OS X app good enough to start testing with, even
if it doesn't get everything quite right yet.
This change is almost entirely rearranging existing code, so it
shouldn't be seriously destabilising. But two noticeable actual
changes have happened, both pleasantly simplifying:
Firstly, the global-variables rewrite of gtkcomm.c has allowed the
post_main edifice to become a great deal simpler. Most of its
complexity was about remembering what 'inst' it had to call back to,
and in fact the right answer is that it shouldn't be calling back to
one at all. So now the post_main() called by gtkdlg.c has become the
same function as the old inst_post_main() that actually did the work,
instead of the two having to be connected by a piece of ugly plumbing.
Secondly, a piece of code that's vanished completely in this
refactoring is the temporary blocking of SIGCHLD around most of the
session setup code. This turns out to have been introduced in 2002,
_before_ I switched to using the intra-process signal pipe strategy
for SIGCHLD handling in 2003. So I now expect that we should be robust
in any case against receiving SIGCHLD at an inconvenient moment, and
hence there's no need to block it.
When we're displaying bidirectionally active text (that is, text that
the Unicode bidi algorithm will fiddle with), we need to suppress
Pango's bidi because we've already done our own. We were doing this by
calling is_rtl() on each character, and if it returned true,
displaying just that character in a separate Pango call.
Except that, ahem, we were only doing this if the _first_ character
encountered during a scan of the display buffer was rtl-sensitive. If
the first one was fine but a subsequent one was rtl-sensitive, then
that one would just get shoved into the buffer we'd already started.
Running pterm -fn 'client:Monospace 12' and displaying
testdata/utf8.txt now works again.
When I cut it in half so I could fetch the XCharStruct for a given
character, I forgot that the remaining half should check whether it
had got NULL from the XCharStruct finder. Ahem.
If you run something like 'seq 2000000000' in a GTK3 pterm, the window
never actually updates, because pterm always considers reading more
data from the pty to have higher priority than delivering the "draw"
event. Using g_io_add_watch_full instead of g_io_add_watch allows us
to explicitly lower the priority of the I/O sources, so that window
redraws will take precedence.
This is quite a pain, since it involves inventing an entire new piece
of infrastructure to install a custom Xlib error handler and give it a
queue of things to do. But it fixes a bug in which Unix pterm/PuTTY
crash out at startup if one of the root window's CUT_BUFFERn
properties contains something of a type other than STRING - in
particular, UTF8_STRING is not unheard-of.
For example, run
xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy"
and then pterm without this fix would have crashed.
I had completely forgotten, when rendering each glyph to a server-side
pixmap and downloading its contents, to only look at the part of the
pixmap that XDrawImageString would have overwritten, as specified by
the metrics in the XCharStruct. Now 'pterm -fn server:variable'
doesn't randomly make up bitmap nonsense outside each character's
bounding rectangle.
GCC 6 emits strict-aliasing warnings here, so use the existing
sockaddr_union arrangements to avoid those. As a prerequisite for being
able to express sk_tcp_peer_info in terms of sockaddr_union, I fixed up
the union elements to be a bit less odd in the NO_IPV6 case.
Now all the uses of the licence text or the short copyright notice get
it from a new header "licence.h", which in turn is built by a Perl
script licence.pl invoked by mkfiles.pl, using LICENCE itself as the
source.
Hence, I can completely remove a whole section from the list of
licence locations in CHECKLST.txt :-)
I've made the licence text, the About box, and the host key dialog
into GTK selectable edit controls. (The former because it contains a
lot of text; the About box because pasting version numbers into bug
reports is obviously useful; the host key because of the fingerprint.)
When we provide an editable text box with a drop-down list of useful
preset values, such as the one full of character sets in the
Translation panel, we implement it on GTK 2.4+ as a GtkComboBox
pointing at a two-column GtkListStore, in which the second column is
the actual text (the first being a numeric id). Therefore, we need to
set the "entry-text-column" property to tell GtkComboBox which of
those columns to look in for the value corresponding to the edit-box
text.
Thanks to Robert de Bath for spotting the problem and tracing it as
far as commit 5fa22495c. That commit replaced a widget construction
call via gtk_combo_box_entry_new_with_model() with one using the newer
gtk_combo_box_new_with_model_and_entry(), overlooking the fact that
the former provided the text column number as a parameter, and the
latter didn't.
I'd missed out an if statement in the Unix proxy stderr code
introduced by commit 297efff30, causing ret->cmd_err to be passed to
uxsel_set even when it was -1 (which happened in the non-GUI tools).
Unfortunately, putting a negative fd into the uxsel tree has really
bad effects, because the first_fd / next_fd interface returns a
negative number to signal end-of-list - and since the uxsel tree is
sorted by fd, that happens _immediately_.
Added the missing if statement, and also an assertion to make sure we
never pass -1 to uxsel_set by mistake again!
gtk_misc_set_alignment was deprecated in GTK 3.14. But my replacement
code using gtk_label_set_xalign doesn't work there, because that
function wasn't introduced until GTK 3.16, so there are two minor
versions in the middle where a third strategy is needed.
It has three settings: on, off, and 'only until session starts'. The
idea of the last one is that if you use something like 'ssh -v' as
your proxy command, you probably wanted to see the initial SSH
connection-setup messages while you were waiting to see if the
connection would be set up successfully at all, but probably _didn't_
want a slew of diagnostics from rekeys disrupting your terminal in
mid-emacs once the session had got properly under way.
Default is off, to avoid startling people used to the old behaviour. I
wonder if I should have set it more aggressively, though.
On both Unix and Windows, we now redirect the local proxy command's
standard error into a third pipe; data received from that pipe is
broken up at newlines and logged in the Event Log. So if the proxy
command emits any error messages in the course of failing to connect
to something, you now have a fighting chance of finding out what went
wrong.
This feature is disabled in command-line tools like PSFTP and Plink,
on the basis that in that situation it seems more likely that the user
would expect standard-error output to go to the ordinary standard
error in the ordinary way. Only GUI PuTTY catches it and logs it like
this, because it either doesn't have a standard error at all (on
Windows) or is likely to be pointing it at some completely unhelpful
session log file (under X).
I've defined a new value for the 'int type' parameter passed to
plug_log(), which proxy sockets will use to pass their backend
information on how the setup of their proxied connections are going.
I've implemented support for the new type code in all _nontrivial_
plug log functions (which, conveniently, are precisely the ones I just
refactored into backend_socket_log); the ones which just throw all
their log data away anyway will do that to the new code as well.
We use the new type code to log the DNS lookup and connection setup
for connecting to a networked proxy, and also to log the exact command
string sent down Telnet proxy connections (so the user can easily
debug mistakes in the configured format string) and the exact command
executed when spawning a local proxy process. (The latter was already
supported on Windows by a bodgy logging call taking advantage of
Windows in particular having no front end pointer; I've converted that
into a sensible use of the new plug_log facility, and done the same
thing on Unix.)
We set up a pair of bufchains for the standard input and output
exchanged with the proxy process, but forgot to clear them when the
Local_Proxy_Socket is cleaned up.
TOOLTYPE_NONNETWORK (i.e. pterm) already has "-log" (as does Unix
PuTTY), so there's no sense suppressing the synonym "-sessionlog".
Undocumented lacunae that remain:
plink accepts -sessionlog, but does nothing with it. Arguably it should.
puttytel accepts -sshlog/-sshrawlog (and happily logs e.g. Telnet
negotiation, as does PuTTY proper).
This saves the need to fork and exec "cat", which should speed things
up. It also ensures that the network output goes to /dev/null, which
should avoid problems with blocking when writing to a full pipe.
In GTK3, the line 'Continue with connection?' got wrapped (in spite of
my attempt to enforce via string_width() that it didn't - probably a
few pixels were needed on top of that for various padding and
furniture) so it looked even sillier. But it looked a bit narrow to be
sensible even in GTK2, so the simplest answer is just to widen it
considerably.
I think it only did so in GTK2 by virtue of the About box being a
GtkDialog. But in GTK3 I've abandoned GtkDialog for not being flexible
enough, so I have to process the Escape key myself.
The askalg() dialog, and several one-button things like the licence
box, have no button labelled 'cancel'. But in all cases we do want
Escape to terminate the box, with as negative an answer as is
available. So now we assign the 'iscancel' flag to any button whose
numeric value is the smallest of the ones given as input to
messagebox().
(In a one-button box, this leads to isdefault and iscancel _both_
being set for that button. That's fine; it works.)
I had put an entire piece of code into win_key_press's SHORTCUT_UCTRL
handler to carefully handle all the different kinds of list box
control and do something sensible with each one, and then I just went
and used a generic SHORTCUT_FOCUS type shortcut instead of actually
_calling_ all that carefully prepared code.
Now selecting (say) the character-classes list box in the Selection
panel using its Alt-e shortcut works; also, shortcut-selecting a popup
menu such as the ones in the Bugs panel causes the menu to pop up,
which I think is nicer than what previously happened.
I'd failed to set the widget field in its shortcut structure, leading
to an annoying GTK warning log message and no useful UI action when
Alt-G was pressed in the config box.
I had originally planned to implement a Compose-type key locally in
GTK PuTTY, as I did in Windows PuTTY. But in fact we've done this for
some time by delegating to the GTK IM system, which is a far better
idea anyway. So there's no point any more having the FIXME comment
that mentions Compose keys.
Also, there was a comment worrying about what I was going to do about
double-width characters in Pango, which is long since sorted out.
Fixes a behaviour which I intended all along but apparently didn't
work before on GTK: if you start PuTTY, _select_ a saved session in
the list box but don't hit Load, and then just hit Open, then it will
be implicitly loaded and run for you, as a special case to save you an
extra button-press.
This depends on noticing that the saved-sessions list box last had the
focus, for which I need my widget_focus() handler to be called for
basically all config widgets so that I can track what _did_ last have
focus. Unfortunately, I missed a couple out.
The previous sequence of events was that I would display the window
synchronously (via gtk_widget_show_now), so that I knew it was
actually on the screen and realised as an X window, and then I'd grab
the keyboard, and once the keyboard was grabbed, connect up the
keyboard event handlers and display the prompt.
I have to assume that deferring the display of the 'enter the
passphrase' prompt until the keyboard handlers were set up was
intended as some sort of 'not misleading the user' measure - don't
tell them to start typing until we're actually ready to start typing.
But unfortunately it has the side effect that the window is displayed
at a much smaller size before the prompt label appears, and centred on
the screen according to _that_ size - and then we display the prompt
label and the window resizes and is now off-centre. So I think it's
better not to try to be clever, and just make the window come up at
the right size initially.
(Actually, it looks as if nothing in the window is actually drawn
until that whole init function is finished anyway, so the prompt label
_already_ doesn't get physically displayed too early. So the whole
idea was pointless in the first place!)
When displaying a server-side font, the unified font selector's
font-style list box contains some lines which are character-set
headings, and others which are actually selectable font styles. We tag
the former with the "sensitive"=FALSE attribute, to prevent them from
responding to clicks. In GTK2, this also made them visually distinct
from the normal lines, by greying them out; in GTK3 it makes no visual
difference.
The simplest solution is to bold those lines, hinting that they're
sort of section headings. That looks OK in GTK2 as well, so I've done
it unconditionally.
The top-level loop in gtkwin.c which draws text was expecting that the
right way to draw a printing character plus combining characters was
to overprint them one by one on top of each other. This is an OK
assumption for X bitmap fonts, but in Pango, it works very badly -
most obviously because asking Pango to display a combining char on its
own causes it to print a dotted circle representing the base char, but
also because surely there will be character combinations where Pango
wants to do something more sophisticated than just printing them each
at a standard offset, and it would be a shame not to let it.
So I've moved the previous overprinting loop down into the x11font
subclass of the unifont mechanism. The top-level gtkwin.c drawing code
now calls a new method unifont_draw_combining, which in the X11 case
does the same loop as before, but in the Pango case, just passes a
whole base+combinings string to Pango in one go and lets it do the
best job it can.
Touchpad gestures can generate much smoother scrolling events than the
discrete increments of mouse wheels. GDK3 supports this by means of a
new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a
floating-point delta value. Added support for this; so in GTK3 mode,
you can now touchpad-scroll at a granularity of one line rather than
five, but in mouse tracking mode, scroll events are still grouped into
5-line chunks for purposes of turning them into escape sequences to
send to the server.
Apparently, if you don't specify GDK_SMOOTH_SCROLL_MASK in a widget's
event mask, then you don't receive "scroll_event" signals at all, even
of the non-smooth variety that was all GTK2 had. Hence, neither mouse
scroll wheels nor touchpad scroll gestures seem to generate any
response.
Adding GDK_SMOOTH_SCROLL_MASK brings the old scroll events back again,
so this is at least no worse than GTK2 was. But in GTK3 we _ought_ to
be able to do better still, by supporting smooth scrolling from
touchpads; this commit doesn't do that.
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.
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.
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.
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).
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.
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.
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...)
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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"
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.
