mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-25 01:02:24 +00:00
19b12ee56c
When the terminal asks its TermWin for a resize, the resize operation happens asynchronously (or can do), and sooner or later, the terminal will see a term_size() telling it the resize has actually taken effect. If the resize _doesn't_ take effect for any reason - e.g. because the window is maximised, or because the X11 window manager is a tiling one which will refuse requests to change the window size anyway - then the terminal never got any explicit notification of refusal to resize. Now it should, in as many cases as I can arrange. One obvious case of this is the early exit I recently added to gtkwin_request_resize() when the window is known to be in a maximised or tiled state preventing a resize: in that situation, when our own code knows we're not even attempting the resize, we also queue a toplevel callback to tell the terminal so. The more interesting case is when the request is refused for a reason GTK _didn't_ know in advance, e.g. because the user is running an X11 tiling window manager such as i3, which generally refuses windows' resize requests. In X11, if a window manager refuses an attempt to change the window's size via ConfigureWindow, ICCCM says it should respond by sending a synthetic ConfigureNotify event restating the same size. Such no-op configure events do reach the "configure_event" handler in a GTK program, but they weren't previously getting as far as term_size(), because the call to term_size() was triggered from the GTK "size_allocate" event on the GtkDrawingArea inside the window (via drawing_area_setup()), so GTK would detect that nothing had changed. Now we queue a last-ditch toplevel callback which ensures that if the configure event doesn't also cause a size_allocate and a call to drawing_area_setup(), then we cause one of our own once the dust has settled. And drawing_area_setup(), in turn, now unconditionally calls term_size() even if the size is the same as it was last time, instead of taking an early exit. (It still does take an early exit to avoid unnecessary faffing with Cairo surfaces etc, but _after_ term_size()). This won't be 100% reliable, because it's the window manager's responsibility to send those synthetic ConfigureNotify events, and a window manager is a fallible process which could get into a stuck state. But it covers all the cases I know of that _can_ be sensibly covered - so now, when terminal.c asks the front end to resize the window, it ought to find out in a timely manner whether or not that has happened, in _almost_ all cases. |
||
---|---|---|
charset | ||
cmake | ||
contrib | ||
crypto | ||
doc | ||
icons | ||
keygen | ||
otherbackends | ||
proxy | ||
ssh | ||
stubs | ||
terminal | ||
test | ||
unix | ||
utils | ||
windows | ||
.gitignore | ||
aqsync.c | ||
be_list.c | ||
Buildscr | ||
Buildscr.cv | ||
callback.c | ||
cgtest.c | ||
CHECKLST.txt | ||
clicons.c | ||
CMakeLists.txt | ||
cmdgen.c | ||
cmdline.c | ||
config.c | ||
console.c | ||
console.h | ||
defs.h | ||
dialog.c | ||
dialog.h | ||
errsock.c | ||
import.c | ||
LATEST.VER | ||
ldisc.c | ||
LICENCE | ||
licence.pl | ||
logging.c | ||
marshal.h | ||
misc.h | ||
mksrcarc.sh | ||
mkunxarc.sh | ||
mpint.h | ||
network.h | ||
pageant.c | ||
pageant.h | ||
pinger.c | ||
pscp.c | ||
psftp.c | ||
psftp.h | ||
psftpcommon.c | ||
psocks.c | ||
psocks.h | ||
putty.h | ||
puttymem.h | ||
README | ||
release.pl | ||
settings.c | ||
sign.sh | ||
ssh.h | ||
sshcr.h | ||
sshkeygen.h | ||
sshpubk.c | ||
sshrand.c | ||
storage.h | ||
timing.c | ||
tree234.h | ||
version.h | ||
x11disp.c |
This is the README for PuTTY, a free Windows and Unix Telnet and SSH client. PuTTY is built using CMake <https://cmake.org/>. To compile in the simplest way (on any of Linux, Windows or Mac), run these commands in the source directory: cmake . cmake --build . Documentation (in various formats including Windows Help and Unix `man' pages) is built from the Halibut (`.but') files in the `doc' subdirectory using `doc/Makefile'. If you aren't using one of our source snapshots, you'll need to do this yourself. Halibut can be found at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>. The PuTTY home web site is https://www.chiark.greenend.org.uk/~sgtatham/putty/ If you want to send bug reports or feature requests, please read the Feedback section of the web site before doing so. Sending one-line reports saying `it doesn't work' will waste your time as much as ours. See the file LICENCE for the licence conditions.