font selector: I had got the row and column counts in
gtk_table_new() back to front, so the space on the right was the
padding around five empty table columns! (And apparently a GtkTable
silently expands if you try to use rows that don't exist, which is
why I hadn't already noticed.)
Fixed that, and added some padding around the entire table. I think
my font selector is now finished, except for any bug fixes that come
up in testing.
[originally from svn r7954]
during an entire run of unifontsel (because unifontsel_set_name was
either not called at all, or called with a name that didn't
correspond to any known font). In this situation we grey out the OK
button until a valid font is selected, and we have
unifontsel_get_name return NULL rather than failing an assertion if
it should be called in that state. The current client code in
gtkdlg.c should never encounter a NULL return, since it only calls
it after the OK button is clicked, but I've stuck an assertion in
there too on general principles.
[originally from svn r7953]
character at a time centred in its character cell, as we do for
Pango. Gives much better results for those non-monospaced fonts
which are usable as terminal fonts, and shows up the problems with
the others more readily. (In particular, this means the preview pane
in the font selector now warns you there will be trouble if you
select such a font.)
[originally from svn r7949]
selectors, preserve their most recent size selection as faithfully
as possible. We do this by having a secondary size variable
indicating what they _intend_, so we can come back to their intended
size even after going through a font which doesn't include it.
[originally from svn r7947]
we can call it both when the drawing area changes size and when the
selected font changes. As a result, the preview pane doesn't start
off blank any more.
[originally from svn r7945]
them automatically. If the user selects an alias in the font
selector, they get that alias copied literally into the output font
name string; when they return to the font selector, the alias is
still selected. We still _can_ resolve aliases, but we only do it on
demand: double-clicking one in the list box will do the job.
[originally from svn r7944]
instead of alphabetical order. This is more than cosmetic: it's
important because the first one in the list is selected by default.
[originally from svn r7941]
latter require manual input to the Makefile, since the Pango
developers in their unbounded wisdom (that is, unbounded below)
didn't bother to start providing the PANGO_VERSION macros until
release 1.16 - ten releases _after_ everything I'm trying to check!
[originally from svn r7940]
sizable TODO at the top of gtkfont.c - but it's basically functional
enough to select fonts of both types, so I'm checking it in now
before I accidentally break it.
[originally from svn r7938]
some point too: introduce a bunch of environment variables which can
override Unix PuTTY's usual idea of where to find its dotfiles.
Setting PUTTYDIR moves the entire ~/.putty directory; setting
PUTTYSESSIONS, PUTTYSSHHOSTKEYS or PUTTYRANDOMSEED move specific
things within that directory.
While I'm here, also be prepared to fall back to password file
lookups if $HOME is undefined (though we still use $HOME in
preference when it is defined, because that's polite and useful).
Also, on general principles, tweak the make_filename() function
prototype so it doesn't rely on fixed-size buffers.
[originally from svn r7934]
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
problems using Unix PuTTY port forwarding. Sockets we create by
connect() are immediately set into nonblocking mode by fcntl, but
sockets we create by accept() were not. This trivial fix should help.
[originally from svn r7864]
the backend's unthrottle function. If we don't, we'll deadlock. While
we're here, also pump as much data as possible out during each call to
try_output(), rather than restricting ourselves to a single call to
write().
[originally from svn r7755]
except that O_NONBLOCK is standardised and FIONBIO isn't. In consequence,
replace our only use of FIONBIO with O_NONBLOCK.
Inspired by Jonathan H N Chin, who had problems with this on Solaris.
[originally from svn r7753]
descriptor into non-blocking mode temporarily, and correctly handle returns
of EAGAIN from write(). This should fix unix-plink-stdout-nonblock, while
avoiding EAGAIN turning up where we aren't expecting it.
[originally from svn r7748]
completely broke interactive logins. The problem, or at least one of the
problems, was that in interactive use stdin, stdout, and stderr tend to be
the same file, so setting O_NONBLOCK on the latter two also sets it on the
former. Thus, we need to cope with all of them being non-blocking.
[originally from svn r7742]
[r7738 == d0db31a1ca]
the entire process because stdout is busy.
Arguably, this shouldn't apply to stderr when we're printing our own error
messages to it, but I'll leave that fix for another time.
[originally from svn r7738]
port number in the GUI when the connection type is changed if the current
port number is the standard one for the current protocol.
It's not perfect, but it should make the common case of tabbing through the
Session panel easier when starting non-SSH connections on odd ports.
[originally from svn r7635]
Should be no significant change in behaviour.
(Well, entering usernames containing commas on Plink's command line will be
a little harder now.)
[originally from svn r7628]
box on button-up rather than button-down. The effect of this is that
if a saved session is already selected in the list box and then you
double-click it, it will open rather than beeping annoyingly.
[originally from svn r7414]
simply specifying a hostname on the command line -- this would bring up the
config dialog. Use a slightly more sophisticated notion of whether the user
meant to launch a session.
[originally from svn r7321]
[r7265 == 5d76e00dac]
represent a launchable session, unless the user can be construed to
have really meant it. This means:
- starting up PuTTY when the Default Settings are launchable still
brings up the config box, and you have to hit Open to actually
launch that session
- double-clicking on Default Settings from the config box will load
them but not launch them.
On the other hand:
- explicitly loading the Default Settings on the command line using
`-load' _does_ still launch them.
[originally from svn r7265]
appears to merely fix the background colour (arranging for it to
have transparency rather than being on some kind of default grey
background), but it turns out to also fix the strange blurry
behaviour I see in the GNOME Taskbar, for no very obvious reason.
[originally from svn r7186]
inside one single uxsel front end, better to do it centrally and
avoid passing zero flags on to the front end in the first place. I'm
sure other similarly structured front ends could get confused by it
too.
[originally from svn r7171]
[r7164 == 65f9735b95]
want to know about any input events on a socket, it's simpler not to
call gdk_input_add() on it at all.
I hesitate to say `fixes', but ... this change _causes to go away_
the weird problem I had with blank host key dialogs. I have no
understanding of the chain of cause and effect between gdk_input_add
with zero flags and missing redraw events, but it seems like a
change I should make anyway, so I'm going to do so and hope the
problem doesn't come back :-/
[originally from svn r7164]
