This is a little like schedule_timer, in that the callback you provide
will be run from the top-level message loop of whatever application
you're in; but unlike the timer mechanism, it will happen
_immediately_.
The aim is to provide a general way to avoid re-entrance of code, in
cases where just _doing_ the thing you want done is liable to trigger
a confusing recursive call to the function in which you came to the
decision to do it; instead, you just request a top-level callback at
the message loop's earliest convenience, and do it then.
[originally from svn r10019]
immediately after conf_deserialise in the Duplicate Session receiver,
whereas I should have put it after the subsequent loop that extracts
the pty argv if any.
[originally from svn r9943]
[r9919 == ea301bdd9b]
segfaults if a PuTTY or pterm did not close on exit and then you
either typed something via input_method_commit_event or changed the
line editing or echo settings.
[originally from svn r9908]
and returns its error message as a string, instead of actually
printing it on standard error and exiting. Now we can preserve the
previous error behaviour when we get a nonexistent font name at
startup time, but no longer rudely terminate in mid-session if the
user configures a bogus font name in Change Settings.
[originally from svn r9745]
Well, at least across all command-line tools on both Windows and Unix,
and the GTK apps on Unix too. The Windows GUI apps fundamentally can't
write to standard output and it doesn't seem sensible to use message
boxes for these purposes :-)
[originally from svn r9673]
First, make absolute times unsigned. This means that it's safe to
depend on their overflow behaviour (which is undefined for signed
integers). This requires a little extra care in handling comparisons,
but I think I've correctly adjusted them all.
Second, functions registered with schedule_timer() are guaranteed to be
called with precisely the time that was returned by schedule_timer().
Thus, it's only necessary to check these values for equality rather than
doing risky range checks, so do that.
The timing code still does lots that's undefined, unnecessary, or just
wrong, but this is a good start.
[originally from svn r9667]
zero but does it in such a way that over-clever compilers hopefully
won't helpfully optimise the call away if you do it just before
freeing something or letting it go out of scope. Use this for
(hopefully) every memset whose job is to destroy sensitive data that
might otherwise be left lying around in the process's memory.
[originally from svn r9586]
piece of keyboard handling: if Num Lock is on, numeric keypad keys are
eaten by the IM, so we must avoid passing them to the IM in the first
place if we're in any non-default numeric keypad mode (application or
Nethack).
This is a grubby way to do it, but the more obvious approach of just
moving the Nethack and app-keypad if statements up to above the IM
call doesn't work because those statements depend on the generic
Alt-prefix handling that happens just _below_ the IM call. So instead
I just repeat the list of keystrokes and modes in an if statement
conditionalising the IM call.
[originally from svn r9573]
[r9567 == 7fc8db15b2]
a GtkIMMulticontext and having that filter most keypresses. I think
I've got this right so that it doesn't break any previous deliberate
keyboard-handling behaviour that's now _after_ the 'if (filter
keypress) return' statement.
[originally from svn r9567]
remembered to do before! Also some related fixes, such as that after
we do so we should immediately stop selecting on the socket in
question.
[originally from svn r9363]
allocated type.
The main reason for this is to stop it from taking up a fixed large
amount of space in every 'struct value' subunion in conf.c, although
that makes little difference so far because Filename is still doing
the same thing (and is therefore next on my list). However, the
removal of its arbitrary length limit is not to be sneezed at.
[originally from svn r9314]
by introducing a wrapper around an individual unifont which falls back
to Pango (which already has built-in fallback) in the case where the
selected font doesn't support the glyph in question.
The wrapper itself is a (vestigial) subclass of unifont, to minimise
disturbance at the call sites.
[originally from svn r9293]
individual font implementation as wchar_t, rather than having to be
converted by the client into the appropriate MBCS/SBCS.
This also means I can remove 'real_charset' from the public-facing
contents of the unifont structure.
[originally from svn r9292]
data channels. Should comprehensively fix 'half-closed', in principle,
though it's a big and complicated change and so there's a good chance
I've made at least one mistake somewhere.
All connections should now be rigorous about propagating end-of-file
(or end-of-data-stream, or socket shutdown, or whatever) independently
in both directions, except in frontends with no mechanism for sending
explicit EOF (e.g. interactive terminal windows) or backends which are
basically always used for interactive sessions so it's unlikely that
an application would be depending on independent EOF (telnet, rlogin).
EOF should now never accidentally be sent while there's still buffered
data to go out before it. (May help fix 'portfwd-corrupt', and also I
noticed recently that the ssh main session channel can accidentally
have MSG_EOF sent before the output bufchain is clear, leading to
embarrassment when it subsequently does send the output).
[originally from svn r9279]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
in saved sessions, so that a programmable window manager can
distinguish different PuTTYs/pterms on startup and assign them
different window management properties.
[originally from svn r9078]
function in terminal.c, and replace the cloned-and-hacked handling
code in all our front ends with calls to that.
This was intended for code cleanliness, but a side effect is to make
the GTK arrow-key handling support disabling of application cursor
key mode in the Features panel. Previously that checkbox was
accidentally ignored, and nobody seems to have noticed before!
[originally from svn r8896]
sessions submenu of the terminal window context menu (as Pageant does), rather
than an empty menu (which often renders poorly).
[originally from svn r8648]
'string' field in a GdkEventKey structure as ISO-8859-1, which was
correct for GTK 1.2 but in 2.0 that field is encoded according to
the current C library locale. Hence, we now process that field by
converting it to UTF-8 via trips through both libc and libcharset,
and then let lpage_send() convert from UTF-8 back to whatever it's
supposed to actually go down the line in.
[originally from svn r8470]
list of selection targets offered by GTK PuTTY/pterm grows an extra
copy of each of the three supported text formats every time the user
makes a selection!
[originally from svn r8364]
called from within a backend function which will expect its own
backend pointer to still be valid on return. Instead, move all the
real functionality of notify_remote_exit() out into a GTK idle
function.
[originally from svn r8304]
with the switch to GTK2. This turns out to be because, where GTK1
represented the scroll wheel as mouse buttons 4 and 5 and generated
GdkEventButton when it was moved, GTK2 has moved wheel actions out
into a new event type GdkEventScroll which we were not handling. Now
we do, so scroll wheel support should be back in place.
[originally from svn r8063]
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
gtk_container_dequeue_resize_handler in request_resize() was;
everything seems to work fine without it. So I'm removing the
nonportable GTK 2 instance of it, and if anything ever goes wrong as
a result then I'll at least find out what the problem was.
[originally from svn r7957]
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]
