not -1 (it turns out _most_ X fonts prefer the former, though
irritatingly my favourite real X font used to prefer the latter
which was why I made the X version of my Font Of Choice do so too),
and also clip to the boundaries of the rectangle we should be
drawing text in. This still doesn't completely prevent display
corruption in the case where text drawn in one sweep is partially
overwritten in a future one, but gnome-terminal has this problem
too, and now we've got the right default SB offset _and_ offer the
opportunity to reconfigure it I think this is pretty good for now.
[originally from svn r2184]
doesn't hang when you hit ^C, which is nice. I think a better
solution would involve nonblocking sockets; as it stands it's a
little dependent on what may be quirks of the Linux socket layer.
[originally from svn r2175]
doesn't yet use the SSH agent, no way to specify arbitrary config
options, no manpage yet, couple of other fiddly things need doing,
but it makes SSH connections and doesn't fall over horribly so I say
it's a good start. Now to run it under valgrind...
[originally from svn r2165]
this init sequence - it surely can't be right that `pterm --help'
with no DISPLAY complains at the lack of DISPLAY rather than giving
a help message!
[originally from svn r2164]
source files in which it's no longer required (it was previously
required in anything that included <putty.h>, but not any more).
Also moved a couple of stray bits of exposed WinSock back into
winnet.c (getservbyname from ssh.c and AF_INET from proxy.c).
[originally from svn r2160]
mode==BELL_VISUAL, otherwise taskbar flashing won't happen on visual
bells. It's up to the frontend routine to spot BELL_VISUAL and avoid
making any noise.
[originally from svn r2155]
into line with most other xtermalikes. On Unix, the exit code of a
shell is the last exit code of one of its child processes, even if
it's an interactive shell - so some pterms will close and some will
not for no particularly good reason. Power-detaching a screen
session is especially bad for this.
COE_NORMAL is still useful for specialist purposes (running a single
command in its own pterm), but I don't think it's a sane default,
unfortunately.
[originally from svn r2154]
a pterm came up while Alt was down, then releasing it would cause a
^@ to be generated. Also, though, I've decided that Alt plus a
single numberpad key should not generate a low-numbered control
code, because that's too easy to do by mistake and the codes are too
powerful. Anyone who really _wants_ to create a ^C or ^D from the
numberpad can do Alt-03 or Alt-04 easily enough; two-digit codes and
more such as Alt-65 are unaffected.
[originally from svn r2153]
absent, and also (I think) all the frontend request functions (such
as request_resize) take a context pointer, so that multiple windows
can be handled sensibly. I wouldn't swear to this, but I _think_
that only leaves the Unicode stuff as the last stubborn holdout.
[originally from svn r2147]
lpage_send out into the line discipline, making them _clients_ of
the Unicode layer rather than part of it. This means they can access
ldisc->term, which in turn means I've been able to remove the
temporary global variable `term'. We're slowly getting there.
[originally from svn r2143]
As a result I've now been able to turn the global variables `back'
and `backhandle' into module-level statics in the individual front
ends. Now _that's_ progress!
[originally from svn r2142]
now compiles and runs again after the major destabilisation.
Unfortunately it wasn't feasible to actually encapsulate all of the
pty backend's data, since the utmp helper and the need to fork and
drop privileges before doing anything else at all rather confuses
matters. So the data handle passed around to the pty backend is a
null pointer, and the pty backend is just as global-ridden as it
always has been. Shame, but such is life.
[originally from svn r2128]
only on clean exit, which is a departure from most xterm-alikes but
Ian reckons people will love me for it. If this turns out to be
wrong, we can always change the default for Unix.
[originally from svn r2120]
terminal.c was apparently relying on implicit initialisation to
zero, and also I've removed the backends' dependency on terminal.h
by having terminal sizes explicitly passed in to back->size().
[originally from svn r2117]
all the global and function-static variables out of terminal.c into
a dynamically allocated data structure. Note that this does not yet
confer the ability to run more than one of them in the same process,
because other things (the line discipline, the back end) are still
global, and also in particular the address of the dynamically
allocated terminal-data structure is held in a global variable
`term'. But what I've got here represents a reasonable stopping
point at which to check things in. In _theory_ this should all still
work happily, on both Unix and Windows. In practice, who knows?
[originally from svn r2115]
it's automatically deactivated by any keypress, so that command-line
beeps from (e.g.) filename completion don't suddenly stop occurring,
but it still provides a rapid response to an accidental spewing of a
binary to your terminal.
[originally from svn r2107]
set[ug]id. All privs-requiring pty operations are done at the very
start of the run, then privs are dropped before initialising GTK.
Utmp is handled by forking a still-privileged subprocess at this
point, and later asking it (through a pipe) to stamp utmp. The
subprocess cleans up utmp on exit, which has the additional
advantage that if the main pterm process suffers some sort of
unexpected termination (up to and including SIGKILL) the subprocess
can still mop up utmp.
[originally from svn r2082]
which to pipe printed data. Of course by default printing is
disabled; typically cfg.printer would be set to `lpr', perhaps with
some arguments.
[originally from svn r2073]
send a button 4 press for an upward wheel movement and a button 5
press for a downward one). Untested since my own trackball's button
4 does nothing obvious. Someone with a mouse wheel should give this
a workout.
[originally from svn r2069]
rather than the gtk_window_set_policy approach; the GNOME people say
that the former is the Right Thing in spite of the latter looking
obviously plausible.
[originally from svn r2066]
want a new option to configure it to be on the LHS though. And some
lunatic is bound to ask for an xterm-style scrollbar too... :-)
[originally from svn r2062]
including server-controlled resizing. Irritatingly I've had to use a
deprecated option to gtk_window_set_policy() to make this work,
resulting in me raising GNOME bug #95818 to ask for it to be un-
deprecated again...
[originally from svn r2061]
login shell or not. Also moved these new pieces of configuration
into the Config structure, though they won't stay there forever
since they will need to be moved out into platform-dependent config.
[originally from svn r2060]
terminals right. Irritatingly this was working when run from another
[xsp]term but not when run from my GNOME panel. I think it's now
more robust.
[originally from svn r2041]
us select our own mouse pointer fg and bg for standard pointers?
It's ludicrous that we can only do it for pixmap-derived ones. :-( )
[originally from svn r2035]
pick up the font's real width and height. This means I now _can't_
use my font of choice until I implement some command-line options; I
wonder what feature will appear next :-)
[originally from svn r2027]
loopback interface; pterm now runs $SHELL and gives every impression
of being not a bad terminal emulator. I'm quite pleased with that. :-)
[originally from svn r2015]
would have been better to abstract the general key-handling rules
away from the platform-specific keysyms rather than doing clone-
and-hack as I've done - but it'll serve for now. Now all I need is a
real pty back end and pterm should be a just-about-usable prototype.
[originally from svn r2013]
This means pterm actually _looks_ like the PuTTY terminal emulator
engine, instead of merely giving evidence to the expert eye that
said engine is hidden in there somewhere :-)
[originally from svn r2011]
The current pty.c backend is temporarily a loopback device for
terminal emulator testing, the display handling is only just enough
to show that terminal.c is functioning, the keyboard handling is
laughable, and most features are absent. Next step: bring output and
input up to a plausibly working state, and put a real pty on the
back to create a vaguely usable prototype. Oh, and a scrollbar would
be nice too.
In _theory_ the Windows builds should still work fine after this...
[originally from svn r2010]
beginning of a Unix port. It's nowhere near done, and currently it
won't even compile on Unix. But this represents the start of the
process of separating out platform-specific code, and also contains
the mkfiles.pl changes required to support a Unix makefile and a
non-flat source tree.
[originally from svn r1993]
Ben Harris
Simon Tatham