nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
f58ddf26fe
putty-source/unix/window.c

5680 lines
191 KiB
C
Raw Normal View History

Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* window.c: the main code that runs a PuTTY terminal emulator and
Rename some of the more stupidly named files in the Unix back end. Notably pterm.c, which was a sensible name right at the start but became a misnomer as soon as I created Unix PuTTY. [originally from svn r5053]
2004-12-31 13:02:46 +00:00
* backend in a GTK window.
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
*/
Implement handling of all Close On Exit modes. Default is to close 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]
2002-10-23 14:21:12 +00:00
#define _GNU_SOURCE
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
#include <string.h>
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
#include <assert.h>
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
#include <stdlib.h>
Implement handling of all Close On Exit modes. Default is to close 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]
2002-10-23 14:21:12 +00:00
#include <string.h>
#include <signal.h>. Compiled fine without it on Debian 3.0, but not on 2.2. Wonder what changed. [originally from svn r2277]
2002-12-04 12:40:36 +00:00
#include <signal.h>
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
#include <stdio.h>
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
#include <time.h>
And that's it! pty.c is now a real pty backend rather than a 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]
2002-10-10 12:40:05 +00:00
#include <errno.h>
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#include <locale.h>
And that's it! pty.c is now a real pty backend rather than a 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]
2002-10-10 12:40:05 +00:00
#include <fcntl.h>
#include <unistd.h>
Implement handling of all Close On Exit modes. Default is to close 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]
2002-10-23 14:21:12 +00:00
#include <sys/types.h>
#include <sys/wait.h>
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
#include <gtk/gtk.h>
GTK 3 prep: do not include individual GTK/GDK headers. This is the first of several cleanup steps recommended by the GTK 2->3 migration guide. I intend to begin work towards compatibility with GTK 3, but without breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is still useful to _me_ (not least because it permits much easier support of old-style server-side X11 fonts), and I recall hearing a rumour that at least one kind of strange system can only run GTK 1, so for the moment I don't intend to stop supporting either. Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does not include it. In GTK 3 it does, so we don't explicitly reinclude it ourselves. We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But that doesn't say much, because we did already! Apparently gdkkeysyms.h was a special case which that #define didn't forbid.)
2015-08-08 14:06:15 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
#include <gdk/gdkkeysyms.h>
GTK 3 prep: do not include individual GTK/GDK headers. This is the first of several cleanup steps recommended by the GTK 2->3 migration guide. I intend to begin work towards compatibility with GTK 3, but without breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is still useful to _me_ (not least because it permits much easier support of old-style server-side X11 fonts), and I recall hearing a rumour that at least one kind of strange system can only run GTK 1, so for the moment I don't intend to stop supporting either. Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does not include it. In GTK 3 it does, so we don't explicitly reinclude it ourselves. We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But that doesn't say much, because we did already! Apparently gdkkeysyms.h was a special case which that #define didn't forbid.)
2015-08-08 14:06:15 +00:00
#endif
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
#include <gtk/gtkimmodule.h>
#endif
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
#define MAY_REFER_TO_GTK_IN_HEADERS
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
#include "putty.h"
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
#include "terminal.h"
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
#include "gtkcompat.h"
Rename most of the platform source files. This gets rid of all those annoying 'win', 'ux' and 'gtk' prefixes which made filenames annoying to type and to tab-complete. Also, as with my other recent renaming sprees, I've taken the opportunity to expand and clarify some of the names so that they're not such cryptic abbreviations.
2021-04-23 05:19:05 +00:00
#include "unifont.h"
Move more functions into the new gtkmisc.c. 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!
2015-08-31 14:44:24 +00:00
#include "gtkmisc.h"
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
Introduce a config option for building on OS X GTK. 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.
2015-08-31 12:05:51 +00:00
#ifndef NOT_X_WINDOWS
#include <gdk/gdkx.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>
#endif
Ignore X11 BadMatch errors during cut buffer setup. 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.
2016-03-20 18:16:43 +00:00
#include "x11misc.h"
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
GdkAtom compound_text_atom, utf8_string_atom;
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static GdkAtom clipboard_atom
GTK1 build fixes. Looks as if I haven't retried the GTK1 build for a while, and recent GTK frontend development has broken it. The selection revamp has pointed out that GTK1 didn't have the accessor function gtk_selection_data_get_selection(), the standard GdkAtom value GDK_SELECTION_CLIPBOARD, or keysyms for alphabetic characters; and also I had an initialisation of one of my own structure fields (dp->selparams) accidentally not guarded by the same GTK-versioning ifdef that controls whether or not it was defined.
2018-03-03 18:18:54 +00:00
#if GTK_CHECK_VERSION(2,0,0) /* GTK1 will have to fill this in at startup */
= GDK_SELECTION_CLIPBOARD
#endif
;
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
/*
* Because calling gtk_clipboard_set_with_data triggers a call to the
* clipboard_clear function from the last time, we need to arrange a
* way to distinguish a real call to clipboard_clear for the _new_
* instance of the clipboard data from the leftover call for the
* outgoing one. We do this by setting the user data field in our
* gtk_clipboard_set_with_data() call, instead of the obvious pointer
* to 'inst', to one of these.
*/
struct clipboard_data_instance {
char *pasteout_data_utf8;
int pasteout_data_utf8_len;
struct clipboard_state *state;
struct clipboard_data_instance *next, *prev;
};
#endif
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
int clipboard;
GdkAtom atom;
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
GtkClipboard *gtkclipboard;
struct clipboard_data_instance *current_cdi;
#else
char *pasteout_data, *pasteout_data_ctext, *pasteout_data_utf8;
int pasteout_data_len, pasteout_data_ctext_len, pasteout_data_utf8_len;
#endif
};
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
typedef struct XpmHolder XpmHolder; /* only used for GTK 1 */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
struct GtkFrontend {
Window title configurability: -T to set it from the command line, support for the xterm escape sequences to set it, and support for the xterm escape sequence to query it. [originally from svn r2040]
2002-10-14 00:05:37 +00:00
GtkWidget *window, *area, *sbar;
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
gboolean sbar_visible;
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
gboolean drawing_area_got_size, drawing_area_realised;
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
gboolean drawing_area_setup_needed;
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
bool drawing_area_setup_called;
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
GtkBox *hbox;
GtkAdjustment *sbar_adjust;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
GtkWidget *menu, *specialsmenu, *specialsitem1, *specialsitem2,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*restartitem;
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
GtkWidget *sessionsmenu;
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
#ifndef NOT_X_WINDOWS
Display *disp;
#endif
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#ifndef NO_BACKING_PIXMAPS
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
/*
* Server-side pixmap which we use to cache the terminal window's
* contents. When we draw text in the terminal, we draw it to this
* pixmap first, and then blit from there to the actual window;
* this way, X expose events can be handled with an absolute
* minimum of network traffic, by just sending a command to
* re-blit an appropriate rectangle from this pixmap.
*/
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
GdkPixmap *pixmap;
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#endif
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
#ifdef DRAW_TEXT_CAIRO
/*
* If we're drawing using Cairo, we cache the same image on the
* client side in a Cairo surface.
*
* In GTK2+Cairo, this happens _as well_ as having the server-side
* pixmap cache above; in GTK3+Cairo, server-side pixmaps are
* deprecated, so we _just_ have this client-side cache. In the
* latter case that means we have to transmit a big wodge of
* bitmap data over the X connection on every expose event; but
* GTK3 apparently deliberately provides no way to avoid that
* inefficiency, and at least this way we don't _also_ have to
* redo any font rendering just because the window was temporarily
* covered.
*/
cairo_surface_t *surface;
#endif
GTK: Refresh backing surface when border is reconfigured. If you go to Change Settings in Unix PuTTY or pterm, and change the 'Gap between text and window edge' setting but not the width and height, then change_settings_menuitem() correctly sets the physical window to a new size, but drawing_area_setup() was not recreating the backing surface / pixmap in the same way, because it hadn't spotted that the border size might be relevant. Now I unconditionally work out what the exact size of the backing surface _ought_ to be, before reaching the potential early exit path, and never take the early exit if the backing area needs resizing for any reason at all. (I think this probably ought to have been part of commit 528513dde.)
2019-10-20 17:47:04 +00:00
int backing_w, backing_h;
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
GtkIMContext *imc;
#endif
Refactor the font handling code: I've moved all the code that 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]
2008-03-22 11:40:23 +00:00
unifont *fonts[4]; /* normal, bold, wide, widebold */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int xpos, ypos, gravity;
bool gotpos;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
GdkCursor *rawcursor, *textcursor, *blankcursor, *waitcursor, *currcursor;
Bring some order to colour palette indexing. There are three separate indexing schemes in use by various bits of the PuTTY front ends, and _none_ of them was clearly documented, let alone all in the same place. Worse, functions that looked obviously related, like win_palette_set and win_palette_get, used different encodings. Now all the encodings are defined together in putty.h, with explanation of why there are three in the first place and clear documentation of where each one is used; terminal.c provides mapping tables that convert between them; the terminology is consistent throughout; and win_palette_set has been converted to use the sensible encoding.
2021-02-07 19:59:20 +00:00
GdkColor cols[OSC4_NCOLOURS]; /* indexed by xterm colour indices */
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
GdkColormap *colmap;
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
#endif
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool direct_to_font;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state clipstates[N_CLIPBOARDS];
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
/* Remember all clipboard_data_instance structures currently
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
* associated with this GtkFrontend, in case they're still around
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
* when it gets destroyed */
struct clipboard_data_instance cdi_headtail;
#endif
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
int clipboard_ctrlshiftins, clipboard_ctrlshiftcv;
Stop hard-coding a nonstandard font. We now default to `fixed', and 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]
2002-10-10 14:42:56 +00:00
int font_width, font_height;
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
int width, height, scale;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool ignore_sbar;
bool mouseptr_visible;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
BusyStatus busy_status;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
int alt_keycode;
Fix Alt+numberpad in pterm. For a start, there was a bug whereby if 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]
2002-10-28 17:34:45 +00:00
int alt_digits;
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
char *wintitle;
char *icontitle;
pterm now uses the new uxsel module, so it's one step closer to being able to be a PuTTY as well as a pterm. In the process I've also moved icky things like actually reading from the pty fd and printing the `terminated on signal' messages into pty.c where they obviously should have been in the first place. Also there's been one interesting repercussion in the terminal code: terminal.c's from_backend now calls term_out() directly rather than expecting the front end to call it afterwards. This has had the entertaining side effect of fixing a Windows-specific bug whereby activity in a port forwarding through a PuTTY with a blinking cursor caused the cursor to blink to ON (!!!!). So, a surprisingly far-reaching checkin as it turns out... [originally from svn r3017]
2003-03-29 18:30:14 +00:00
int master_fd, master_func_id;
Expose the Ldisc structure tag throughout the code. That's one fewer anonymous 'void *' which might be accidentally confused with some other pointer type if I misremember the order of function arguments. While I'm here, I've made its pointer-nature explicit - that is, 'Ldisc' is now a typedef for the structure type itself rather than a pointer to it. A stylistic change only, but it feels more natural to me these days for a thing you're going to eventually pass to a 'free' function.
2018-09-11 14:02:59 +00:00
Ldisc *ldisc;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
Backend *backend;
Reorganised the Unicode layer somewhat: moved luni_send and 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]
2002-10-26 11:08:59 +00:00
Terminal *term;
Fix command-line password handling in Restart Session. When the user provides a password on the PuTTY command line, via -pw or -pwfile, the flag 'tried_once' inside cmdline_get_passwd_input() is intended to arrange that we only try sending that password once, and after we've sent it, we don't try again. But this plays badly with the 'Restart Session' operation. If the connection is lost and then restarted at user request, we _do_ want to send that password again! So this commit moves that static variable out into a small state structure held by the client of cmdline_get_passwd_input. Each client can decide how to manage that state itself. Clients that support 'Restart Session' - i.e. just GUI PuTTY itself - will initialise the state at the same time as instantiating the backend, so that every time the session is restarted, we return to (correctly) believing that we _haven't_ yet tried the password provided on the command line. But clients that don't support 'Restart Session' - i.e. Plink and file transfer tools - can do the same thing that cmdline.c was doing before: just keep the state in a static variable. This also means that the GUI login tools will now retain the command-line password in memory, whereas previously they'd have wiped it out once it was used. But the other tools will still wipe and free the password, because I've also added a 'bool restartable' flag to cmdline_get_passwd_input to let it know when it _is_ allowed to do that. In the GUI tools, I don't see any way to get round that, because if the session is restarted you _have_ to still have the password to use again. (And you can't infer that that will never happen from the CONF_close_on_exit setting, because that too could be changed in mid-session.) On the other hand, I think it's not all that worrying, because the use of either -pw or -pwfile means that a persistent copy of your password is *already* stored somewhere, so another one isn't too big a stretch. (Due to the change of -pw policy in 0.77, the effect of this bug was that an attempt to reconnect in a session set up this way would lead to "Configured password was not accepted". In 0.76, the failure mode was different: PuTTY would interactively prompt for the password, having wiped it out of memory after it was used the first time round.)
2022-05-18 12:04:56 +00:00
cmdline_get_passwd_input_state cmdline_get_passwd_state;
Make 'LogContext' a typedef visible throughout the code. Same principle again - the more of these structures have globally visible tags (even if the structure contents are still opaque in most places), the fewer of them I can mistake for each other.
2018-09-11 14:17:16 +00:00
LogContext *logctx;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool exited;
Deglobalise the Unicode module. Despite all my grand plans, I've just done this the very simple way - bundle all the globals into a data structure and pass pointers around. One particularly ugly wart is that wc_to_mb now takes a pointer to this structure as an argument (optional, may be NULL, and unused in any Unicode layer that's even marginally less of a mess than the Windows one). I do need to do this properly at some point, but for now this should just about be adequate. As usual, the Mac port has not been updated. [originally from svn r2592]
2003-01-14 18:28:23 +00:00
struct unicode_data ucsdata;
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
Conf *conf;
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlog_stuff *eventlogstuff;
Richard Boulton's patch for improved correctness in selection handling (generally, selection request timestamps should be set to the timestamp on the event that caused them). [originally from svn r3408]
2003-08-21 18:03:06 +00:00
guint32 input_event_time; /* Timestamp of the most recent input event. */
Expand the dialog registering/unregistering system. Now it has several 'slots', each named for a particular class of subsidiary dialog box that a session window can have at most one of, and register_network_prompt_dialog has a more general name and takes an enum-typed argument identifying a slot. This lets me avoid writing a zillion annoyingly similar function pairs and corresponding snippets of cleanup code in delete_inst.
2017-11-26 16:51:19 +00:00
GtkWidget *dialogs[DIALOG_SLOT_LIMIT];
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
#if GTK_CHECK_VERSION(3,4,0)
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
gdouble cumulative_hscroll, cumulative_vscroll;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
#endif
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
/* Cached things out of conf that we refer to a lot */
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
int bold_style;
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
int window_border;
int cursor_type;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
int drawtype;
On OS X, be able to configure either Option or Command as Meta. 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.
2015-09-01 18:00:25 +00:00
int meta_mod_mask;
OS X: pass Command key back to GTK if it's not being Meta. This fixes the problem I'd previously noticed, that if you don't configure the "Command key acts as Meta" setting, then keystrokes like Command-Q which _ought_ to function as accelerators for the application menu bar don't. Turns out that this was for the totally obvious reason: the keyboard event was still being processed by gtkwin.c's key_event() and translated via the GTK IM into ordinary keyboard input. If instead I return FALSE from key_event on detecting that a key event has a non-Meta-configured Command modifier, then it will go to the next- level key-event handler inside GTK itself which implements the menu accelerator behaviour. Another problem ticked off the OS X checklist.
2017-12-18 10:43:13 +00:00
#ifdef OSX_META_KEY_CONFIG
int system_mod_mask;
#endif
Make send_raw_mouse a field of GtkFrontend. I came across this unexplained static variable in my boolification trawl. It seems clearly unintentional that it has only one instance instead of one per terminal window - the code in question closely resembles the Windows front end, and I think this must just be a variable that I never swept up into 'inst' in the very early days when I was making gtkwin.c out of a cloned-and-hacked window.c in the first place. These days it's even a bug, now that the OS X port actually does run multiple terminal windows in the same process: if one goes into mouse reporting mode, I'm pretty sure this would have done confusing things to the effects of mouse actions in the other.
2018-11-03 08:17:44 +00:00
bool send_raw_mouse;
Decouple frontend's raw mouse mode from pointer shape. This paves the way for a followup commit that will make them happen at slightly different times.
2021-02-07 19:59:21 +00:00
bool pointer_indicates_raw_mouse;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
unifont_drawctx uctx;
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
#if GTK_CHECK_VERSION(2,0,0)
GdkPixbuf *trust_sigil_pb;
#else
GdkPixmap *trust_sigil_pm;
#endif
int trust_sigil_w, trust_sigil_h;
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
Move window resize timeouts into the GTK frontend. In the changes around commit 420fe75552afa94, I made the terminal suspend output processing while it waited for a term_size() callback in response to a resize request. Because on X11 there are unusual circumstances in which you never receive that callback, I also added a last-ditch 5-second timeout, so that eventually we'll resume terminal output processing regardless. But the timeout lives in terminal.c, in the cross-platform code. This is pointless on Windows (where resize processing is synchronous, so we always finish it before the timer code next gets called anyway), but I decided it was easier to keep the whole mechanism in terminal.c in the absence of a good reason not to. Now I've found that reason. We _also_ generate window resizes locally to the GTK front end, in response to the key combinations that change the font size, and _those_ still have an asynchrony problem. So, to begin with, I'm refactoring the request_resize system so that now there's an explicit callback from the frontend to the terminal to say 'Your resize request has now been processed, whether or not you've received a term_size() call'. On Windows, this simplifies matters greatly because we always know exactly when to call that, and don't have to keep a 'have we called term_size() already?' flag. On GTK, the timing complexity previously in terminal.c has moved into window.c. No functional change (I hope). The payoff will be in the next commit.
2022-05-12 17:16:56 +00:00
/*
* Not every GDK backend can be relied on 100% to reply to a
* resize request in a timely manner. (In X11 it's all
* asynchronous and goes via the window manager, and if your
* window manager is seriously unwell, you'd rather not have
* terminal windows start becoming unusable as a knock-on effect,
* since those are just the thing you might need to use for
* emergency WM maintenance!)
*
* So when we ask GTK to resize our terminal window, we also set a
* 5-second timer, after which we'll regretfully conclude that a
* resize (or ConfigureNotify telling us no resize took place) is
* probably not going to happen after all.
*/
bool win_resize_pending, term_resize_notification_required;
long win_resize_timeout;
#define WIN_RESIZE_TIMEOUT (TICKSPERSEC*5)
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Seat seat;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
TermWin termwin;
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
LogPolicy logpolicy;
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
};
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void cache_conf_values(GtkFrontend *inst)
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
{
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
inst->bold_style = conf_get_int(inst->conf, CONF_bold_style);
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
inst->window_border = conf_get_int(inst->conf, CONF_window_border);
inst->cursor_type = conf_get_int(inst->conf, CONF_cursor_type);
On OS X, be able to configure either Option or Command as Meta. 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.
2015-09-01 18:00:25 +00:00
#ifdef OSX_META_KEY_CONFIG
inst->meta_mod_mask = 0;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(inst->conf, CONF_osx_option_meta))
On OS X, be able to configure either Option or Command as Meta. 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.
2015-09-01 18:00:25 +00:00
inst->meta_mod_mask |= GDK_MOD1_MASK;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(inst->conf, CONF_osx_command_meta))
On OS X, be able to configure either Option or Command as Meta. 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.
2015-09-01 18:00:25 +00:00
inst->meta_mod_mask |= GDK_MOD2_MASK;
OS X: pass Command key back to GTK if it's not being Meta. This fixes the problem I'd previously noticed, that if you don't configure the "Command key acts as Meta" setting, then keystrokes like Command-Q which _ought_ to function as accelerators for the application menu bar don't. Turns out that this was for the totally obvious reason: the keyboard event was still being processed by gtkwin.c's key_event() and translated via the GTK IM into ordinary keyboard input. If instead I return FALSE from key_event on detecting that a key event has a non-Meta-configured Command modifier, then it will go to the next- level key-event handler inside GTK itself which implements the menu accelerator behaviour. Another problem ticked off the OS X checklist.
2017-12-18 10:43:13 +00:00
inst->system_mod_mask = GDK_MOD2_MASK & ~inst->meta_mod_mask;
On OS X, be able to configure either Option or Command as Meta. 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.
2015-09-01 18:00:25 +00:00
#else
inst->meta_mod_mask = GDK_MOD1_MASK;
#endif
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void start_backend(GtkFrontend *inst);
Revamp GTK's session close handling using toplevel callbacks. Instead of having a special GTK idle function for dealing with session closing, I now use the new top-level callback mechanism which is slightly simpler for calling a one-off function. Also in this commit, I've arranged for connection_fatal to queue a call to the same session close function after displaying the message box, with the effect that now all the same processing takes place no matter whether the session closes cleanly or uncleanly - e.g. the SSH specials submenu is cleaned out, as it should be. [originally from svn r10022]
2013-08-17 16:06:22 +00:00
static void exit_callback(void *vinst);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void destroy_inst_connection(GtkFrontend *inst);
static void delete_inst(GtkFrontend *inst);
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
static void post_fatal_message_box_toplevel(void *vctx)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)vctx;
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
gtk_widget_destroy(inst->window);
}
static void post_fatal_message_box(void *vctx, int result)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)vctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
unregister_dialog(&inst->seat, DIALOG_SLOT_CONNECTION_FATAL);
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
queue_toplevel_callback(post_fatal_message_box_toplevel, inst);
}
Unix GUI: honour 'no close on exit' for connection_fatal. It was being treated like an application-fatal message box even if you'd configured the window not to close on an unclean exit.
2018-09-28 17:28:24 +00:00
static void common_connfatal_message_box(
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst, const char *msg, post_dialog_fn_t postfn)
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
{
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
char *title = dupcat(appname, " Fatal Error");
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
GtkWidget *dialog = create_message_box(
inst->window, title, msg,
string_width("REASONABLY LONG LINE OF TEXT FOR BASIC SANITY"),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
false, &buttons_ok, postfn, inst);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
register_dialog(&inst->seat, DIALOG_SLOT_CONNECTION_FATAL, dialog);
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
sfree(title);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void fatal_message_box(GtkFrontend *inst, const char *msg)
Unix GUI: honour 'no close on exit' for connection_fatal. It was being treated like an application-fatal message box even if you'd configured the window not to close on an unclean exit.
2018-09-28 17:28:24 +00:00
{
common_connfatal_message_box(inst, msg, post_fatal_message_box);
}
Introduce a typedef for frontend handles. This is another major source of unexplained 'void *' parameters throughout the code. In particular, the currently unused testback.c actually gave the wrong pointer type to its internal store of the frontend handle - it cast the input void * to a Terminal *, from which it got implicitly cast back again when calling from_backend, and nobody noticed. Now it uses the right type internally as well as externally.
2018-09-12 08:10:51 +00:00
static void connection_fatal_callback(void *vctx)
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)vctx;
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
destroy_inst_connection(inst);
}
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
Unix GUI: honour 'no close on exit' for connection_fatal. It was being treated like an application-fatal message box even if you'd configured the window not to close on an unclean exit.
2018-09-28 17:28:24 +00:00
static void post_nonfatal_message_box(void *vctx, int result)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)vctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
unregister_dialog(&inst->seat, DIALOG_SLOT_CONNECTION_FATAL);
Unix GUI: honour 'no close on exit' for connection_fatal. It was being treated like an application-fatal message box even if you'd configured the window not to close on an unclean exit.
2018-09-28 17:28:24 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void gtk_seat_connection_fatal(Seat *seat, const char *msg)
Various error-handling fixes, mostly in Unix PuTTY but one (failure to save a session) crosses over into the platform-independent side. [originally from svn r3041]
2003-04-01 18:10:25 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Unix GUI: honour 'no close on exit' for connection_fatal. It was being treated like an application-fatal message box even if you'd configured the window not to close on an unclean exit.
2018-09-28 17:28:24 +00:00
if (conf_get_int(inst->conf, CONF_close_on_exit) == FORCE_ON) {
fatal_message_box(inst, msg);
} else {
common_connfatal_message_box(inst, msg, post_nonfatal_message_box);
}
Revamp GTK's session close handling using toplevel callbacks. Instead of having a special GTK idle function for dealing with session closing, I now use the new top-level callback mechanism which is slightly simpler for calling a one-off function. Also in this commit, I've arranged for connection_fatal to queue a call to the same session close function after displaying the message box, with the effect that now all the same processing takes place no matter whether the session closes cleanly or uncleanly - e.g. the SSH specials submenu is cleaned out, as it should be. [originally from svn r10022]
2013-08-17 16:06:22 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->exited = true; /* suppress normal exit handling */
Introduce a typedef for frontend handles. This is another major source of unexplained 'void *' parameters throughout the code. In particular, the currently unused testback.c actually gave the wrong pointer type to its internal store of the frontend handle - it cast the input void * to a Terminal *, from which it got implicitly cast back again when calling from_backend, and nobody noticed. Now it uses the right type internally as well as externally.
2018-09-12 08:10:51 +00:00
queue_toplevel_callback(connection_fatal_callback, inst);
Various error-handling fixes, mostly in Unix PuTTY but one (failure to save a session) crosses over into the platform-independent side. [originally from svn r3041]
2003-04-01 18:10:25 +00:00
}
New Seat method, seat_nonfatal(). This is like the seat-independent nonfatal(), but specifies a Seat, which allows the GUI dialog box to have the right terminal window as its parent (if there are multiple ones). Changed over all the nonfatal() calls in the code base that could be localised to a Seat, which means all the ones that come up if something goes horribly wrong in host key storage. To make that possible, I've added a 'seat' parameter to store_host_key(); it turns out that all its call sites had one available already.
2022-09-13 07:49:38 +00:00
static void gtk_seat_nonfatal(Seat *seat, const char *msg)
{
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
nonfatal_message_box(inst->window, msg);
}
I'm sick of all those #ifdefs in settings.c, and in any case plink and pterm need at least one default setting to be _different_ (pterm needs the default term type to be `xterm', while plink needs it to be taken from $TERM). So here's a completely new alternative mechanism for platform- and app-specific default settings. Ben will probably want to check the integrity of the Mac port, since I've fiddled with it without testing that it still compiles. [originally from svn r2513]
2003-01-09 18:06:29 +00:00
/*
* Default settings that are specific to pterm.
*/
Change the semantics of 'FontSpec' so that it's a dynamically 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]
2011-10-01 17:38:59 +00:00
FontSpec *platform_default_fontspec(const char *name)
I'm sick of all those #ifdefs in settings.c, and in any case plink and pterm need at least one default setting to be _different_ (pterm needs the default term type to be `xterm', while plink needs it to be taken from $TERM). So here's a completely new alternative mechanism for platform- and app-specific default settings. Ben will probably want to check the integrity of the Mac port, since I've fiddled with it without testing that it still compiles. [originally from svn r2513]
2003-01-09 18:06:29 +00:00
{
if (!strcmp(name, "Font"))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return fontspec_new(DEFAULT_GTK_FONT);
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
else
Add platform-independent fontspec_new_default() function. Constructing a FontSpec in platform-independent code is awkward, because you can't call fontspec_new() outside the platform subdirs (since its prototype varies per platform). But sometimes you just need _some_ valid FontSpec, e.g. to put in a Conf that will be used in some place where you don't actually care about font settings, such as a purely CLI program. Both Unix and Windows _have_ an idiom for this, but they're different, because their FontSpec constructors have different prototypes. The existing CLI tools have always had per-platform main source files, so they just use the locally appropriate method of constructing a boring don't-care FontSpec. But if you want a _platform-independent_ main source file, such as you might find in a test program, then that's rather awkward. Better to have a platform-independent API for making a default FontSpec.
2023-02-18 13:43:50 +00:00
return fontspec_new_default();
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
}
Turn 'Filename' into a dynamically allocated type with no arbitrary length limit, just as I did to FontSpec yesterday. [originally from svn r9316]
2011-10-02 11:01:57 +00:00
Filename *platform_default_filename(const char *name)
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
{
if (!strcmp(name, "LogFileName"))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return filename_from_str("putty.log");
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return filename_from_str("");
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
}
char *platform_default_s(const char *name)
{
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
if (!strcmp(name, "SerialLine"))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return dupstr("/dev/ttyS0");
I'm sick of all those #ifdefs in settings.c, and in any case plink and pterm need at least one default setting to be _different_ (pterm needs the default term type to be `xterm', while plink needs it to be taken from $TERM). So here's a completely new alternative mechanism for platform- and app-specific default settings. Ben will probably want to check the integrity of the Mac port, since I've fiddled with it without testing that it still compiles. [originally from svn r2513]
2003-01-09 18:06:29 +00:00
return NULL;
}
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
bool platform_default_b(const char *name, bool def)
{
if (!strcmp(name, "WinNameAlways")) {
/* X natively supports icon titles, so use 'em by default */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
}
return def;
}
Miscellaneous fixes to finish up `remove-statics'. rlogin.c had a holdout static I hadn't noticed; unicode.c had one too; and a large number of statics that were perfectly OK due to being constants have been made `const', with assorted `const' repercussions all over the place. I now declare `remove-statics' to be fixed. [originally from svn r2594]
2003-01-14 18:43:45 +00:00
int platform_default_i(const char *name, int def)
I'm sick of all those #ifdefs in settings.c, and in any case plink and pterm need at least one default setting to be _different_ (pterm needs the default term type to be `xterm', while plink needs it to be taken from $TERM). So here's a completely new alternative mechanism for platform- and app-specific default settings. Ben will probably want to check the integrity of the Mac port, since I've fiddled with it without testing that it still compiles. [originally from svn r2513]
2003-01-09 18:06:29 +00:00
{
if (!strcmp(name, "CloseOnExit"))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 2; /* maps to FORCE_ON after painful rearrangement :-( */
I'm sick of all those #ifdefs in settings.c, and in any case plink and pterm need at least one default setting to be _different_ (pterm needs the default term type to be `xterm', while plink needs it to be taken from $TERM). So here's a completely new alternative mechanism for platform- and app-specific default settings. Ben will probably want to check the integrity of the Mac port, since I've fiddled with it without testing that it still compiles. [originally from svn r2513]
2003-01-09 18:06:29 +00:00
return def;
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static char *gtk_seat_get_ttymode(Seat *seat, const char *mode)
First crack at `terminal-modes' in SSH. PuTTY now sends ERASE by default, Unix Plink sends everything sensible it can find, and it's fully configurable from the GUI. I'm not entirely sure about the precise set of modes that Unix Plink should look at; informed tweaks are welcome. Also the Mac bits are guesses (but trivial). [originally from svn r5653] [this svn revision also touched putty-wishlist]
2005-04-21 13:57:08 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
First crack at `terminal-modes' in SSH. PuTTY now sends ERASE by default, Unix Plink sends everything sensible it can find, and it's fully configurable from the GUI. I'm not entirely sure about the precise set of modes that Unix Plink should look at; informed tweaks are welcome. Also the Mac bits are guesses (but trivial). [originally from svn r5653] [this svn revision also touched putty-wishlist]
2005-04-21 13:57:08 +00:00
return term_get_ttymode(inst->term, mode);
}
seat_output: add an output type for SSH banners. (NFC) The jump host system ought really to be treating SSH authentication banners as a distinct thing from the standard-error session output, so that the former can be presented to the user in the same way as the auth banner for the main session. This change converts the 'bool is_stderr' parameter of seat_output() into an enumerated type with three values. For the moment, stderr and banners are treated the same, but the plan is for that to change.
2021-09-16 13:46:49 +00:00
static size_t gtk_seat_output(Seat *seat, SeatOutputType type,
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
const void *data, size_t len)
Rationalisation of the system of frontend handles. Most modular bits of PuTTY (terminal, backend, logctx etc) take a `void *' handle passed to them from the frontend, and used as a context for all their callbacks. Most of these point at the frontend structure itself (on platforms where this is meaningful), except that the handle passed to the backend has always pointed at the terminal because from_backend() was implemented in terminal.c. This has finally bitten Unix PuTTY, because both backend and logctx have been passing their respective and very different frontend handles to logevent(), so I've fixed it. from_backend() is now a function supplied by the _frontend_ itself, in all cases, and the frontend handle passed to backends must be the same as that passed to everything else. What was from_backend() in terminal.c is now called term_data(), and the typical implementation of from_backend() in a GUI frontend will just extract the terminal handle from the frontend structure and delegate to that. This appears to work on Unix and Windows, but has most likely broken the Mac build. [originally from svn r3100]
2003-04-11 18:36:27 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Remove 'is_stderr' parameter from term_data. It wasn't actually used for anything, and removing it now will save me deciding what to do with it in the next commit.
2021-09-16 13:50:59 +00:00
return term_data(inst->term, data, len);
Rationalisation of the system of frontend handles. Most modular bits of PuTTY (terminal, backend, logctx etc) take a `void *' handle passed to them from the frontend, and used as a context for all their callbacks. Most of these point at the frontend structure itself (on platforms where this is meaningful), except that the handle passed to the backend has always pointed at the terminal because from_backend() was implemented in terminal.c. This has finally bitten Unix PuTTY, because both backend and logctx have been passing their respective and very different frontend handles to logevent(), so I've fixed it. from_backend() is now a function supplied by the _frontend_ itself, in all cases, and the frontend handle passed to backends must be the same as that passed to everything else. What was from_backend() in terminal.c is now called term_data(), and the typical implementation of from_backend() in a GUI frontend will just extract the terminal handle from the frontend structure and delegate to that. This appears to work on Unix and Windows, but has most likely broken the Mac build. [originally from svn r3100]
2003-04-11 18:36:27 +00:00
}
Proper buffer management between terminal and backend. The return value of term_data() is used as the return value from the GUI-terminal versions of the Seat output method, which means backends will take it to be the amount of standard-output data currently buffered, and exert back-pressure on the remote peer if it gets too big (e.g. by ceasing to extend the window in that particular SSH-2 channel). Historically, as a comment in term_data() explained, we always just returned 0 from that function, on the basis that we were processing all the terminal data through our terminal emulation code immediately, and never retained any of it in the buffer at all. If the terminal emulation code were to start running slowly, then it would slow down the _whole_ PuTTY system, due to single-threadedness, and back-pressure of a sort would be exerted on the remote by it simply failing to get round to reading from the network socket. But by the time we got back to the top level of term_data(), we'd have finished reading all the data we had, so it was still appropriate to return 0. That comment is still correct if you're thinking about the limiting factor on terminal data processing being the CPU usage in term_out(). But now that's no longer the whole story, because sometimes we leave data in term->inbuf without having processed it: during drag-selects in the terminal window, and (just introduced) while waiting for the response to a pending window resize request. For both those reasons, we _don't_ always have a buffer size of zero when we return from term_data(). So now that hole in our buffer size management is filled in: term_data() returns the true size of the remaining unprocessed terminal output, so that back-pressure will be exerted if the terminal is currently not consuming it. And when processing resumes and we start to clear our backlog, we call backend_unthrottle to let the backend know it can relax the back-pressure if necessary.
2021-12-12 10:57:23 +00:00
static void gtkwin_unthrottle(TermWin *win, size_t bufsize)
{
GtkFrontend *inst = container_of(win, GtkFrontend, termwin);
if (inst->backend)
backend_unthrottle(inst->backend, bufsize);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool gtk_seat_eof(Seat *seat)
Revamp of EOF handling in all network connections, pipes and other 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]
2011-09-13 11:44:03 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
/* GtkFrontend *inst = container_of(seat, GtkFrontend, seat); */
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true; /* do respond to incoming EOF with outgoing */
Revamp of EOF handling in all network connections, pipes and other 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]
2011-09-13 11:44:03 +00:00
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
static SeatPromptResult gtk_seat_get_userpass_input(Seat *seat, prompts_t *p)
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult spr;
Fix command-line password handling in Restart Session. When the user provides a password on the PuTTY command line, via -pw or -pwfile, the flag 'tried_once' inside cmdline_get_passwd_input() is intended to arrange that we only try sending that password once, and after we've sent it, we don't try again. But this plays badly with the 'Restart Session' operation. If the connection is lost and then restarted at user request, we _do_ want to send that password again! So this commit moves that static variable out into a small state structure held by the client of cmdline_get_passwd_input. Each client can decide how to manage that state itself. Clients that support 'Restart Session' - i.e. just GUI PuTTY itself - will initialise the state at the same time as instantiating the backend, so that every time the session is restarted, we return to (correctly) believing that we _haven't_ yet tried the password provided on the command line. But clients that don't support 'Restart Session' - i.e. Plink and file transfer tools - can do the same thing that cmdline.c was doing before: just keep the state in a static variable. This also means that the GUI login tools will now retain the command-line password in memory, whereas previously they'd have wiped it out once it was used. But the other tools will still wipe and free the password, because I've also added a 'bool restartable' flag to cmdline_get_passwd_input to let it know when it _is_ allowed to do that. In the GUI tools, I don't see any way to get round that, because if the session is restarted you _have_ to still have the password to use again. (And you can't infer that that will never happen from the CONF_close_on_exit setting, because that too could be changed in mid-session.) On the other hand, I think it's not all that worrying, because the use of either -pw or -pwfile means that a persistent copy of your password is *already* stored somewhere, so another one isn't too big a stretch. (Due to the change of -pw policy in 0.77, the effect of this bug was that an attempt to reconnect in a session set up this way would lead to "Configured password was not accepted". In 0.76, the failure mode was different: PuTTY would interactively prompt for the password, having wiped it out of memory after it was used the first time round.)
2022-05-18 12:04:56 +00:00
spr = cmdline_get_passwd_input(p, &inst->cmdline_get_passwd_state, true);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
if (spr.kind == SPRK_INCOMPLETE)
spr = term_get_userpass_input(inst->term, p);
return spr;
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool gtk_seat_is_utf8(Seat *seat)
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Remove TermWin's is_utf8 method. All implementations of it work by checking the line_codepage field in the ucsdata structure that the terminal itself already has a pointer to. Therefore, it's a totally unnecessary query function: the terminal can check the same thing directly by inspecting that structure! (In fact, it already _does_ do that, for the purpose of actually deciding how to decode terminal output data. It only uses this query function at all for the auxiliary purpose of inventing useful tty modes to pass to the backend.)
2021-02-07 19:59:20 +00:00
return inst->ucsdata.line_codepage == CS_UTF8;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
}
Restore ability to build with Gtk<3. This got broken in 696550a5f2.
2021-04-05 16:05:10 +00:00
static void get_window_pixel_size(GtkFrontend *inst, int *w, int *h)
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
{
Flip direction of window pos/size queries. Similarly to other recent changes, the frontend now proactively keeps Terminal up to date with the current position and size of the terminal window, so that escape-sequence queries can be answered immediately from the Terminal's own internal data structures without needing a call back to the frontend. Mostly this has let me remove explicit window-system API calls that retrieve the window position and size, in favour of having the front ends listen for WM_MOVE / WM_SIZE / ConfigureNotify events and track the position and size that way. One exception is that the window pixel size is still requested by Seat via a callback, to put in the wire-encoded termios settings. That won't be happening very much, so I'm leaving it this way round for the moment.
2021-02-07 19:59:21 +00:00
/*
* I assume that when the GTK version of this call is available
* we should use it. Not sure how it differs from the GDK one,
* though.
*/
#if GTK_CHECK_VERSION(2,0,0)
gtk_window_get_size(GTK_WINDOW(inst->window), w, h);
#else
gdk_window_get_size(gtk_widget_get_window(inst->window), w, h);
#endif
Restore ability to build with Gtk<3. This got broken in 696550a5f2.
2021-04-05 16:05:10 +00:00
}
static bool gtk_seat_get_window_pixel_size(Seat *seat, int *w, int *h)
{
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
get_window_pixel_size(inst, w, h);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
}
Revise the API for seat_stripctrl_new. Now instead of taking raw arguments to configure the output StripCtrlChars with, it takes an enumerated value giving the context of what's being sanitised, and allows the seat to decide what the output parameters for that context should be. The only context currently used is SIC_BANNER (SSH login banners). I've also added a not-yet-used one for keyboard-interactive prompts.
2019-03-07 08:19:38 +00:00
StripCtrlChars *gtk_seat_stripctrl_new(
Seat *seat, BinarySink *bs_out, SeatInteractionContext sic)
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
{
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Revise the API for seat_stripctrl_new. Now instead of taking raw arguments to configure the output StripCtrlChars with, it takes an enumerated value giving the context of what's being sanitised, and allows the seat to decide what the output parameters for that context should be. The only context currently used is SIC_BANNER (SSH login banners). I've also added a not-yet-used one for keyboard-interactive prompts.
2019-03-07 08:19:38 +00:00
return stripctrl_new_term(bs_out, false, 0, inst->term);
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void gtk_seat_notify_remote_exit(Seat *seat);
static void gtk_seat_update_specials_menu(Seat *seat);
static void gtk_seat_set_busy_status(Seat *seat, BusyStatus status);
#ifndef NOT_X_WINDOWS
Avoid treating non-X GDK display names as X ones When running on Wayland, gdk_display_get_name() can return things like "wayland-0" rather than valid X display names. PuTTY nonetheless treated them as X display names, meaning that when running under Wayland, pterm would set DISPLAY to "wayland-0" in subprocesses, and PuTTY's X forwarding wouldn't work properly. To fix this, places that call gdk_display_get_name() now only do so on displays for which GDK_IS_X_DISPLAY() is true. As with GDK_IS_X_WINDOW(), this requires some backward-compatibility for GDK versions where everything is implicitly running on X. To make this work usefully, pterm now also won't unset DISPLAY if it can't get an X display name and instead will pass through whatever value of DISPLAY it received. I think that's better behaviour anyway. There are two separate parts of PuTTY that call gdk_display_get_name(). platform_get_x_display() in unix/putty.c is used for X forwarding, while gtk_seat_get_x_display() in unix/window.c is used used for setting DISPLAY and recording in utmp. I've updated both of them.
2023-07-15 20:05:41 +00:00
static const char *gtk_seat_get_x_display(Seat *seat);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool gtk_seat_get_windowid(Seat *seat, long *id);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
#endif
Divide seat_set_trust_status into query and update. This complicates the API in one sense (more separate functions), but in another sense, simplifies it (each function does something simpler). When I start putting one Seat in front of another during SSH proxying, the latter will be more important - in particular, it means you can find out _whether_ a seat can support changing trust status without having to actually attempt a destructive modification.
2021-09-12 08:52:46 +00:00
static void gtk_seat_set_trust_status(Seat *seat, bool trusted);
static bool gtk_seat_can_set_trust_status(Seat *seat);
Add a new seat method to return the cursor position. The motivation is for the SUPDUP protocol. The server may send a signal for the terminal to reset any input buffers. After this, the server will not know the state of the terminal, so it is required to send its cursor position back.
2019-04-04 19:17:24 +00:00
static bool gtk_seat_get_cursor_position(Seat *seat, int *x, int *y);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static const SeatVtable gtk_seat_vt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.output = gtk_seat_output,
.eof = gtk_seat_eof,
New Seat callback, seat_sent(). This is used to notify the Seat that some data has been cleared from the backend's outgoing data buffer. In other words, it notifies the Seat that it might be worth calling backend_sendbuffer() again. We've never needed this before, because until now, Seats have always been the 'main program' part of the application, meaning they were also in control of the event loop. So they've been able to call backend_sendbuffer() proactively, every time they go round the event loop, instead of having to wait for a callback. But now, the SSH proxy is the first example of a Seat without privileged access to the event loop, so it has no way to find out that the backend's sendbuffer has got smaller. And without that, it can't pass that notification on to plug_sent, to unblock in turn whatever the proxied connection might have been waiting to send. In fact, before this commit, sshproxy.c never called plug_sent at all. As a result, large data uploads over an SSH jump host would hang forever as soon as the outgoing buffer filled up for the first time: the main backend (to which sshproxy.c was acting as a Socket) would carefully stop filling up the buffer, and then never receive the call to plug_sent that would cause it to start again. The new callback is ignored everywhere except in sshproxy.c. It might be a good idea to remove backend_sendbuffer() entirely and convert all previous uses of it into non-empty implementations of this callback, so that we've only got one system; but for the moment, I haven't done that.
2021-06-27 12:52:48 +00:00
.sent = nullseat_sent,
Split seat_banner from seat_output. Previously, SSH authentication banners were displayed by calling the ordinary seat_output function, and passing it a special value in the SeatOutputType enumeration indicating an auth banner. The awkwardness of this was already showing a little in SshProxy's implementation of seat_output, where it had to check for that special value and do totally different things for SEAT_OUTPUT_AUTH_BANNER and everything else. Further work in that area is going to make it more and more awkward if I keep the two output systems unified. So let's split them up. Now, Seat has separate output() and banner() methods, which each implementation can override differently if it wants to. All the 'end user' Seat implementations use the centralised implementation function nullseat_banner_to_stderr(), which turns banner text straight back into SEAT_OUTPUT_STDERR and passes it on to seat_output. So I didn't have to tediously implement a boring version of this function in GTK, Windows GUI, consoles, file transfer etc.
2021-10-30 16:06:00 +00:00
.banner = nullseat_banner_to_stderr,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.get_userpass_input = gtk_seat_get_userpass_input,
New Seat method, notify_session_started(). This is called by the backend to notify the Seat that the connection has progressed to the point where the main session channel (i.e. the thing that would typically correspond to the client's stdin/stdout) has been successfully set up. The only Seat that implements this method nontrivially is the one in SshProxy, which uses it as an indication that the proxied connection to the remote host has succeeded, and sends the PLUGLOG_CONNECT_SUCCESS notification to its own Plug. Hence, the only backends that need to implement it at the moment are the two SSH-shaped backends (SSH proper and bare-connection / psusan). For other backends, it's not always obvious what 'main session channel' would even mean, or whether it means anything very useful; so I've also introduced a backend flag indicating whether the backend is expecting to call that method at all, so as not to have to spend pointless effort on defining an arbitrary meaning for it in other contexts. So a lot of this patch is just introducing the new method and putting its trivial do-nothing implementation into all the existing Seat methods. The interesting parts happen in ssh/mainchan.c (which actually calls it), and sshproxy.c (which does something useful in response).
2021-09-12 10:48:42 +00:00
.notify_session_started = nullseat_notify_session_started,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.notify_remote_exit = gtk_seat_notify_remote_exit,
New Seat method, notify_remote_disconnect. This notifies the Seat that the entire backend session has finished and closed its network connection - or rather, that it _might_ have done, and that the frontend should check backend_connected() if it wasn't planning to do so already. The existing Seat implementations haven't needed this: the GUI ones don't actually need to do anything specific when the network connection goes away, and the CLI ones deal with it by being in charge of their own event loop so that they can easily check backend_connected() at every possible opportunity in any case. But I'm about to introduce a new Seat implementation that does need to know this, and doesn't have any other way to get notified of it.
2021-05-22 11:47:51 +00:00
.notify_remote_disconnect = nullseat_notify_remote_disconnect,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.connection_fatal = gtk_seat_connection_fatal,
New Seat method, seat_nonfatal(). This is like the seat-independent nonfatal(), but specifies a Seat, which allows the GUI dialog box to have the right terminal window as its parent (if there are multiple ones). Changed over all the nonfatal() calls in the code base that could be localised to a Seat, which means all the ones that come up if something goes horribly wrong in host key storage. To make that possible, I've added a 'seat' parameter to store_host_key(); it turns out that all its call sites had one available already.
2022-09-13 07:49:38 +00:00
.nonfatal = gtk_seat_nonfatal,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.update_specials_menu = gtk_seat_update_specials_menu,
.get_ttymode = gtk_seat_get_ttymode,
.set_busy_status = gtk_seat_set_busy_status,
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
.confirm_ssh_host_key = gtk_seat_confirm_ssh_host_key,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.confirm_weak_crypto_primitive = gtk_seat_confirm_weak_crypto_primitive,
.confirm_weak_cached_hostkey = gtk_seat_confirm_weak_cached_hostkey,
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
.prompt_descriptions = gtk_seat_prompt_descriptions,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.is_utf8 = gtk_seat_is_utf8,
.echoedit_update = nullseat_echoedit_update,
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
#ifdef NOT_X_WINDOWS
Avoid treating non-X GDK display names as X ones When running on Wayland, gdk_display_get_name() can return things like "wayland-0" rather than valid X display names. PuTTY nonetheless treated them as X display names, meaning that when running under Wayland, pterm would set DISPLAY to "wayland-0" in subprocesses, and PuTTY's X forwarding wouldn't work properly. To fix this, places that call gdk_display_get_name() now only do so on displays for which GDK_IS_X_DISPLAY() is true. As with GDK_IS_X_WINDOW(), this requires some backward-compatibility for GDK versions where everything is implicitly running on X. To make this work usefully, pterm now also won't unset DISPLAY if it can't get an X display name and instead will pass through whatever value of DISPLAY it received. I think that's better behaviour anyway. There are two separate parts of PuTTY that call gdk_display_get_name(). platform_get_x_display() in unix/putty.c is used for X forwarding, while gtk_seat_get_x_display() in unix/window.c is used used for setting DISPLAY and recording in utmp. I've updated both of them.
2023-07-15 20:05:41 +00:00
.get_x_display = nullseat_get_x_display,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.get_windowid = nullseat_get_windowid,
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
#else
Avoid treating non-X GDK display names as X ones When running on Wayland, gdk_display_get_name() can return things like "wayland-0" rather than valid X display names. PuTTY nonetheless treated them as X display names, meaning that when running under Wayland, pterm would set DISPLAY to "wayland-0" in subprocesses, and PuTTY's X forwarding wouldn't work properly. To fix this, places that call gdk_display_get_name() now only do so on displays for which GDK_IS_X_DISPLAY() is true. As with GDK_IS_X_WINDOW(), this requires some backward-compatibility for GDK versions where everything is implicitly running on X. To make this work usefully, pterm now also won't unset DISPLAY if it can't get an X display name and instead will pass through whatever value of DISPLAY it received. I think that's better behaviour anyway. There are two separate parts of PuTTY that call gdk_display_get_name(). platform_get_x_display() in unix/putty.c is used for X forwarding, while gtk_seat_get_x_display() in unix/window.c is used used for setting DISPLAY and recording in utmp. I've updated both of them.
2023-07-15 20:05:41 +00:00
.get_x_display = gtk_seat_get_x_display,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.get_windowid = gtk_seat_get_windowid,
#endif
.get_window_pixel_size = gtk_seat_get_window_pixel_size,
.stripctrl_new = gtk_seat_stripctrl_new,
.set_trust_status = gtk_seat_set_trust_status,
Divide seat_set_trust_status into query and update. This complicates the API in one sense (more separate functions), but in another sense, simplifies it (each function does something simpler). When I start putting one Seat in front of another during SSH proxying, the latter will be more important - in particular, it means you can find out _whether_ a seat can support changing trust status without having to actually attempt a destructive modification.
2021-09-12 08:52:46 +00:00
.can_set_trust_status = gtk_seat_can_set_trust_status,
New Seat query, has_mixed_input_stream(). (TL;DR: to suppress redundant 'Press Return to begin session' prompts in between hops of a jump-host configuration, in Plink.) This new query method directly asks the Seat the question: is the same stream of input used to provide responses to interactive login prompts, and the session input provided after login concludes? It's used to suppress the last-ditch anti-spoofing defence in Plink of interactively asking 'Access granted. Press Return to begin session', on the basis that any such spoofing attack works by confusing the user about what's a legit login prompt before the session begins and what's sent by the server after the main session begins - so if those two things take input from different places, the user can't be confused. This doesn't change the existing behaviour of Plink, which was already suppressing the antispoof prompt in cases where its standard input was redirected from something other than a terminal. But previously it was doing it within the can_set_trust_status() seat query, and I've now moved it out into a separate query function. The reason why these need to be separate is for SshProxy, which needs to give an unusual combination of answers when run inside Plink. For can_set_trust_status(), it needs to return whatever the parent Seat returns, so that all the login prompts for a string of proxy connections in session will be antispoofed the same way. But you only want that final 'Access granted' prompt to happen _once_, after all the proxy connection setup phases are done, because up until then you're still in the safe hands of PuTTY itself presenting an unbroken sequence of legit login prompts (even if they come from a succession of different servers). Hence, SshProxy unconditionally returns 'no' to the query of whether it has a single mixed input stream, because indeed, it never does - for purposes of session input it behaves like an always-redirected Plink, no matter what kind of real Seat it ends up sending its pre-session login prompts to.
2021-11-06 14:33:03 +00:00
.has_mixed_input_stream = nullseat_has_mixed_input_stream_yes,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.verbose = nullseat_verbose_yes,
.interactive = nullseat_interactive_yes,
.get_cursor_position = gtk_seat_get_cursor_position,
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
};
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
static void gtk_eventlog(LogPolicy *lp, const char *string)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(lp, GtkFrontend, logpolicy);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
logevent_dlg(inst->eventlogstuff, string);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
static int gtk_askappend(LogPolicy *lp, Filename *filename,
void (*callback)(void *ctx, int result), void *ctx)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(lp, GtkFrontend, logpolicy);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
return gtkdlg_askappend(&inst->seat, filename, callback, ctx);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
}
static void gtk_logging_error(LogPolicy *lp, const char *event)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(lp, GtkFrontend, logpolicy);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
/* Send 'can't open log file' errors to the terminal window.
* (Marked as stderr, although terminal.c won't care.) */
Extra inline helpers seat_{stdout,stderr}_pl. These take a ptrlen in place of separate buffer and length arguments. Switched over to them in lots of places.
2019-03-07 10:17:08 +00:00
seat_stderr_pl(&inst->seat, ptrlen_from_asciz(event));
seat_stderr_pl(&inst->seat, PTRLEN_LITERAL("\r\n"));
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
}
static const LogPolicyVtable gtk_logpolicy_vt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.eventlog = gtk_eventlog,
.askappend = gtk_askappend,
.logging_error = gtk_logging_error,
.verbose = null_lp_verbose_yes,
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
};
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
/*
* Translate a raw mouse button designation (LEFT, MIDDLE, RIGHT)
* into a cooked one (SELECT, EXTEND, PASTE).
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
* In Unix, this is not configurable; the X button arrangement is
* rock-solid across all applications, everyone has a three-button
* mouse or a means of faking it, and there is no need to switch
* buttons around at all.
*/
Fix Unix breakage from term_mouse() revamp too. [originally from svn r2723]
2003-01-25 16:23:48 +00:00
static Mouse_Button translate_button(Mouse_Button button)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
if (button == MBT_LEFT)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return MBT_SELECT;
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
if (button == MBT_MIDDLE)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return MBT_PASTE;
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
if (button == MBT_RIGHT)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return MBT_EXTEND;
Support xterm any-event mouse tracking From https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Any-event-tracking: Any-event mode is the same as button-event mode, except that all motion events are reported, even if no mouse button is down. It is enabled by specifying 1003 to DECSET. Normally the front ends only report mouse events when buttons are pressed, so we introduce a MA_MOVE event with MBT_NOTHING set to indicate such a mouse movement.
2019-12-20 13:56:58 +00:00
if (button == MBT_NOTHING)
return MBT_NOTHING;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0; /* shouldn't happen */
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
/*
* Return the top-level GtkWindow associated with a particular
* front end instance.
*/
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
GtkWidget *gtk_seat_get_window(Seat *seat)
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
return inst->window;
}
GTK: system for not leaving stale network prompt dialogs. When I switch verify_ssh_host_key() and friends over to creating non-modal message boxes and returning to the main loop, there will be a risk that their parent window will need to close for some other reason while the user hasn't answered the pending question yet. (E.g. if the user presses the main session window's close button, which will no longer be a prohibited UI action once the transient dialog is not modal.) At that point we need to get rid of the pending dialog box, both for UI purposes (it would look silly and be confusing to leave it lying around) and for memory management (if the user subsequently clicks OK in such a dialog it would probably try to leave its result somewhere stale). So now there's a mechanism for gtkwin.c remembering what the current 'network prompt dialog' is, if any (in which category I intend to include everything triggered from ssh.c's various reasons for asking crypto-related questions), and cleaning it up when the struct gui_data it belongs to goes away.
2017-11-26 14:55:15 +00:00
/*
* Set and clear a pointer to a dialog box created as a result of the
* network code wanting to ask an asynchronous user question (e.g.
* 'what about this dodgy host key, then?').
*/
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
void register_dialog(Seat *seat, enum DialogSlot slot, GtkWidget *dialog)
GTK: system for not leaving stale network prompt dialogs. When I switch verify_ssh_host_key() and friends over to creating non-modal message boxes and returning to the main loop, there will be a risk that their parent window will need to close for some other reason while the user hasn't answered the pending question yet. (E.g. if the user presses the main session window's close button, which will no longer be a prohibited UI action once the transient dialog is not modal.) At that point we need to get rid of the pending dialog box, both for UI purposes (it would look silly and be confusing to leave it lying around) and for memory management (if the user subsequently clicks OK in such a dialog it would probably try to leave its result somewhere stale). So now there's a mechanism for gtkwin.c remembering what the current 'network prompt dialog' is, if any (in which category I intend to include everything triggered from ssh.c's various reasons for asking crypto-related questions), and cleaning it up when the struct gui_data it belongs to goes away.
2017-11-26 14:55:15 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
assert(seat->vt == &gtk_seat_vt);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst = container_of(seat, GtkFrontend, seat);
Expand the dialog registering/unregistering system. Now it has several 'slots', each named for a particular class of subsidiary dialog box that a session window can have at most one of, and register_network_prompt_dialog has a more general name and takes an enum-typed argument identifying a slot. This lets me avoid writing a zillion annoyingly similar function pairs and corresponding snippets of cleanup code in delete_inst.
2017-11-26 16:51:19 +00:00
assert(slot < DIALOG_SLOT_LIMIT);
assert(!inst->dialogs[slot]);
inst->dialogs[slot] = dialog;
GTK: system for not leaving stale network prompt dialogs. When I switch verify_ssh_host_key() and friends over to creating non-modal message boxes and returning to the main loop, there will be a risk that their parent window will need to close for some other reason while the user hasn't answered the pending question yet. (E.g. if the user presses the main session window's close button, which will no longer be a prohibited UI action once the transient dialog is not modal.) At that point we need to get rid of the pending dialog box, both for UI purposes (it would look silly and be confusing to leave it lying around) and for memory management (if the user subsequently clicks OK in such a dialog it would probably try to leave its result somewhere stale). So now there's a mechanism for gtkwin.c remembering what the current 'network prompt dialog' is, if any (in which category I intend to include everything triggered from ssh.c's various reasons for asking crypto-related questions), and cleaning it up when the struct gui_data it belongs to goes away.
2017-11-26 14:55:15 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
void unregister_dialog(Seat *seat, enum DialogSlot slot)
GTK: system for not leaving stale network prompt dialogs. When I switch verify_ssh_host_key() and friends over to creating non-modal message boxes and returning to the main loop, there will be a risk that their parent window will need to close for some other reason while the user hasn't answered the pending question yet. (E.g. if the user presses the main session window's close button, which will no longer be a prohibited UI action once the transient dialog is not modal.) At that point we need to get rid of the pending dialog box, both for UI purposes (it would look silly and be confusing to leave it lying around) and for memory management (if the user subsequently clicks OK in such a dialog it would probably try to leave its result somewhere stale). So now there's a mechanism for gtkwin.c remembering what the current 'network prompt dialog' is, if any (in which category I intend to include everything triggered from ssh.c's various reasons for asking crypto-related questions), and cleaning it up when the struct gui_data it belongs to goes away.
2017-11-26 14:55:15 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
assert(seat->vt == &gtk_seat_vt);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst = container_of(seat, GtkFrontend, seat);
Expand the dialog registering/unregistering system. Now it has several 'slots', each named for a particular class of subsidiary dialog box that a session window can have at most one of, and register_network_prompt_dialog has a more general name and takes an enum-typed argument identifying a slot. This lets me avoid writing a zillion annoyingly similar function pairs and corresponding snippets of cleanup code in delete_inst.
2017-11-26 16:51:19 +00:00
assert(slot < DIALOG_SLOT_LIMIT);
assert(inst->dialogs[slot]);
inst->dialogs[slot] = NULL;
GTK: system for not leaving stale network prompt dialogs. When I switch verify_ssh_host_key() and friends over to creating non-modal message boxes and returning to the main loop, there will be a risk that their parent window will need to close for some other reason while the user hasn't answered the pending question yet. (E.g. if the user presses the main session window's close button, which will no longer be a prohibited UI action once the transient dialog is not modal.) At that point we need to get rid of the pending dialog box, both for UI purposes (it would look silly and be confusing to leave it lying around) and for memory management (if the user subsequently clicks OK in such a dialog it would probably try to leave its result somewhere stale). So now there's a mechanism for gtkwin.c remembering what the current 'network prompt dialog' is, if any (in which category I intend to include everything triggered from ssh.c's various reasons for asking crypto-related questions), and cleaning it up when the struct gui_data it belongs to goes away.
2017-11-26 14:55:15 +00:00
}
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
/*
* Minimise or restore the window in response to a server-side
* request.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void gtkwin_set_minimised(TermWin *tw, bool minimised)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
/*
* GTK 1.2 doesn't know how to do this.
*/
#if GTK_CHECK_VERSION(2,0,0)
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
if (minimised)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_iconify(GTK_WINDOW(inst->window));
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_deiconify(GTK_WINDOW(inst->window));
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
#endif
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
/*
* Move the window in response to a server-side request.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_move(TermWin *tw, int x, int y)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
/*
* I assume that when the GTK version of this call is available
* we should use it. Not sure how it differs from the GDK one,
* though.
*/
#if GTK_CHECK_VERSION(2,0,0)
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
/* in case we reset this at startup due to a geometry string */
gtk_window_set_gravity(GTK_WINDOW(inst->window), GDK_GRAVITY_NORTH_EAST);
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
gtk_window_move(GTK_WINDOW(inst->window), x, y);
#else
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
gdk_window_move(gtk_widget_get_window(inst->window), x, y);
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
#endif
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
/*
* Move the window to the top or bottom of the z-order in response
* to a server-side request.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void gtkwin_set_zorder(TermWin *tw, bool top)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
if (top)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gdk_window_raise(gtk_widget_get_window(inst->window));
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gdk_window_lower(gtk_widget_get_window(inst->window));
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
/*
* Refresh the window in response to a server-side request.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_refresh(TermWin *tw)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Reorganised the Unicode layer somewhat: moved luni_send and 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]
2002-10-26 11:08:59 +00:00
term_invalidate(inst->term);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
/*
* Maximise or restore the window in response to a server-side
* request.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void gtkwin_set_maximised(TermWin *tw, bool maximised)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
/*
* GTK 1.2 doesn't know how to do this.
*/
#if GTK_CHECK_VERSION(2,0,0)
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
if (maximised)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_maximize(GTK_WINDOW(inst->window));
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_unmaximize(GTK_WINDOW(inst->window));
Support for all the server-side window configuration requests, 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]
2002-10-15 14:31:06 +00:00
#endif
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
/*
* Find out whether a dialog box already exists for this window in a
* particular DialogSlot. If it does, uniconify it (if we can) and
* raise it, so that the user realises they've already been asked this
* question.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool find_and_raise_dialog(GtkFrontend *inst, enum DialogSlot slot)
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
{
GtkWidget *dialog = inst->dialogs[slot];
if (!dialog)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
#if GTK_CHECK_VERSION(2,0,0)
gtk_window_deiconify(GTK_WINDOW(dialog));
#endif
gdk_window_raise(gtk_widget_get_window(dialog));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
}
static void warn_on_close_callback(void *vctx, int result)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)vctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
unregister_dialog(&inst->seat, DIALOG_SLOT_WARN_ON_CLOSE);
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
if (result)
gtk_widget_destroy(inst->window);
}
/*
* Handle the 'delete window' event (e.g. user clicking the WM close
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
* button). The return value false means the window should close, and
* true means it shouldn't.
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
*
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
* (That's counterintuitive, but really, in GTK terms, true means 'I
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
* have done everything necessary to handle this event, so the default
* handler need not do anything', i.e. 'suppress default handler',
* i.e. 'do not close the window'.)
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
gint delete_window(GtkWidget *widget, GdkEvent *event, GtkFrontend *inst)
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
{
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!inst->exited && conf_get_bool(inst->conf, CONF_warn_on_close)) {
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
/*
* We're not going to exit right now. We must put up a
* warn-on-close dialog, unless one already exists, in which
* case we'll just re-emphasise that one.
*/
if (!find_and_raise_dialog(inst, DIALOG_SLOT_WARN_ON_CLOSE)) {
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
char *title = dupcat(appname, " Exit Confirmation");
Mention any extant downstreams in close warning. Suggested by Brian Rak.
2021-02-21 14:17:03 +00:00
char *msg, *additional = NULL;
gtkwin: remove a redundant test in delete_window. We never expect to be passed a NULL GtkFrontend pointer, and even if we were, we'd have crashed several lines above this test. It was benign, of course, but Coverity (which pointed it out) dislikes this kind of thing on the basis that it's confusing - you ought to either test it for NULL properly, or not at all - and I see its point.
2021-04-09 17:10:45 +00:00
if (inst->backend && inst->backend->vt->close_warn_text) {
Mention any extant downstreams in close warning. Suggested by Brian Rak.
2021-02-21 14:17:03 +00:00
additional = inst->backend->vt->close_warn_text(inst->backend);
}
msg = dupprintf("Are you sure you want to close this session?%s%s",
additional ? "\n" : "",
additional ? additional : "");
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
GtkWidget *dialog = create_message_box(
Mention any extant downstreams in close warning. Suggested by Brian Rak.
2021-02-21 14:17:03 +00:00
inst->window, title, msg,
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
string_width("Most of the width of the above text"),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
false, &buttons_yn, warn_on_close_callback, inst);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
register_dialog(&inst->seat, DIALOG_SLOT_WARN_ON_CLOSE, dialog);
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
sfree(title);
Mention any extant downstreams in close warning. Suggested by Brian Rak.
2021-02-21 14:17:03 +00:00
sfree(msg);
sfree(additional);
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Implement Warn On Close. [originally from svn r3099]
2003-04-11 18:15:47 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
}
Remove TermWin's is_minimised method. Again, I've replaced it with a push-based notification going in the other direction, so that when the terminal output stream includes a query for 'is the window minimised?', the Terminal doesn't have to consult the TermWin, because it already knows the answer. The GTK API I'm using here (getting a GdkEventWindowState via GtkWidget's window-state-event) is not present in GTK 1. The API I was previously using (gdk_window_is_viewable) _is_, but it turns out that that API doesn't reliably give the right answer: it only checks visibility of GDK window ancestors, not X window ancestors. So in fact GTK 1 PuTTY/pterm was only ever _pretending_ to reliably support the 'am I minimised' terminal query. Now it won't pretend any more.
2021-02-07 19:59:20 +00:00
#if GTK_CHECK_VERSION(2,0,0)
GTK: fix return type of window-state-event handler. The event should return a 'gboolean', indicating whether the event needs propagating any further. We were returning void, which meant that the default handling might be accidentally suppressed. On Wayland, this had the particularly nasty effect that window redraws would stop completely if you maximised the terminal window. (By trial and error I found that this stopped happening if I removed GDK_HINT_RESIZE_INC from the geometry hints, from which I guess that the default window-state-event handler is doing something important relating to that hint, or would have been if we hadn't accidentally suppressed it. But the bug is clearly here.)
2021-12-18 14:49:11 +00:00
static gboolean window_state_event(
GtkWidget *widget, GdkEventWindowState *event, gpointer user_data)
Remove TermWin's is_minimised method. Again, I've replaced it with a push-based notification going in the other direction, so that when the terminal output stream includes a query for 'is the window minimised?', the Terminal doesn't have to consult the TermWin, because it already knows the answer. The GTK API I'm using here (getting a GdkEventWindowState via GtkWidget's window-state-event) is not present in GTK 1. The API I was previously using (gdk_window_is_viewable) _is_, but it turns out that that API doesn't reliably give the right answer: it only checks visibility of GDK window ancestors, not X window ancestors. So in fact GTK 1 PuTTY/pterm was only ever _pretending_ to reliably support the 'am I minimised' terminal query. Now it won't pretend any more.
2021-02-07 19:59:20 +00:00
{
GtkFrontend *inst = (GtkFrontend *)user_data;
term_notify_minimised(
inst->term, event->new_window_state & GDK_WINDOW_STATE_ICONIFIED);
GTK: fix return type of window-state-event handler. The event should return a 'gboolean', indicating whether the event needs propagating any further. We were returning void, which meant that the default handling might be accidentally suppressed. On Wayland, this had the particularly nasty effect that window redraws would stop completely if you maximised the terminal window. (By trial and error I found that this stopped happening if I removed GDK_HINT_RESIZE_INC from the geometry hints, from which I guess that the default window-state-event handler is doing something important relating to that hint, or would have been if we hadn't accidentally suppressed it. But the bug is clearly here.)
2021-12-18 14:49:11 +00:00
return false;
Remove TermWin's is_minimised method. Again, I've replaced it with a push-based notification going in the other direction, so that when the terminal output stream includes a query for 'is the window minimised?', the Terminal doesn't have to consult the TermWin, because it already knows the answer. The GTK API I'm using here (getting a GdkEventWindowState via GtkWidget's window-state-event) is not present in GTK 1. The API I was previously using (gdk_window_is_viewable) _is_, but it turns out that that API doesn't reliably give the right answer: it only checks visibility of GDK window ancestors, not X window ancestors. So in fact GTK 1 PuTTY/pterm was only ever _pretending_ to reliably support the 'am I minimised' terminal query. Now it won't pretend any more.
2021-02-07 19:59:20 +00:00
}
#endif
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void update_mouseptr(GtkFrontend *inst)
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
{
switch (inst->busy_status) {
case BUSY_NOT:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!inst->mouseptr_visible) {
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
inst->blankcursor);
Decouple frontend's raw mouse mode from pointer shape. This paves the way for a followup commit that will make them happen at slightly different times.
2021-02-07 19:59:21 +00:00
} else if (inst->pointer_indicates_raw_mouse) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
inst->rawcursor);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
inst->textcursor);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
break;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
case BUSY_WAITING: /* XXX can we do better? */
case BUSY_CPU:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* We always display these cursors. */
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
inst->waitcursor);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
default:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unreachable("Bad busy_status");
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
}
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void show_mouseptr(GtkFrontend *inst, bool show)
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 09:58:27 +00:00
{
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(inst->conf, CONF_hide_mouseptr))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
show = true;
Don't cause the mouse pointer to reappear just because it's changed shape. [originally from svn r2053]
2002-10-14 23:39:07 +00:00
inst->mouseptr_visible = show;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
update_mouseptr(inst);
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 09:58:27 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_backing_rect(GtkFrontend *inst);
Debian bug #193013 points out that the (default-)one-pixel border is not redrawn when the window background colour is reconfigured mid- session. In addition, the Official Window Background is not reset, meaning that opaque resizes etc will flicker in the old background colour. This checkin should fix both. [originally from svn r3190]
2003-05-13 18:14:14 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void drawing_area_setup(GtkFrontend *inst, int width, int height)
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int w, h, new_scale;
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Further fiddlings with the size reconfiguration stuff; now everything seems to work right even when the only thing changed was the window border. [originally from svn r3109]
2003-04-12 11:03:44 +00:00
/*
GTK: reinstate accidentally removed calls to term_size. In commit 528513dde I absentmindedly replaced a write to the local variable 'need_size' of drawing_area_setup with a write to inst->drawing_area_setup_needed, imagining that they had the same effect. But actually, need_size was doing two jobs and I only replaced one of them: it was also the variable that indicated that the logical terminal size had changed and so we had to call term_size() to make the terminal.c data structures resize themselves appropriately. The loss of that call also inhibited generation of SIGWINCH.
2018-05-19 06:38:22 +00:00
* See if the terminal size has changed.
Further fiddlings with the size reconfiguration stuff; now everything seems to work right even when the only thing changed was the window border. [originally from svn r3109]
2003-04-12 11:03:44 +00:00
*/
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
w = (width - 2*inst->window_border) / inst->font_width;
h = (height - 2*inst->window_border) / inst->font_height;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
if (w != inst->width || h != inst->height) {
GTK: reinstate accidentally removed calls to term_size. In commit 528513dde I absentmindedly replaced a write to the local variable 'need_size' of drawing_area_setup with a write to inst->drawing_area_setup_needed, imagining that they had the same effect. But actually, need_size was doing two jobs and I only replaced one of them: it was also the variable that indicated that the logical terminal size had changed and so we had to call term_size() to make the terminal.c data structures resize themselves appropriately. The loss of that call also inhibited generation of SIGWINCH.
2018-05-19 06:38:22 +00:00
/*
* Update conf.
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->width = w;
inst->height = h;
conf_set_int(inst->conf, CONF_width, inst->width);
conf_set_int(inst->conf, CONF_height, inst->height);
GTK: reinstate accidentally removed calls to term_size. In commit 528513dde I absentmindedly replaced a write to the local variable 'need_size' of drawing_area_setup with a write to inst->drawing_area_setup_needed, imagining that they had the same effect. But actually, need_size was doing two jobs and I only replaced one of them: it was also the variable that indicated that the logical terminal size had changed and so we had to call term_size() to make the terminal.c data structures resize themselves appropriately. The loss of that call also inhibited generation of SIGWINCH.
2018-05-19 06:38:22 +00:00
/*
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
* We must refresh the window's backing image.
GTK: reinstate accidentally removed calls to term_size. In commit 528513dde I absentmindedly replaced a write to the local variable 'need_size' of drawing_area_setup with a write to inst->drawing_area_setup_needed, imagining that they had the same effect. But actually, need_size was doing two jobs and I only replaced one of them: it was also the variable that indicated that the logical terminal size had changed and so we had to call term_size() to make the terminal.c data structures resize themselves appropriately. The loss of that call also inhibited generation of SIGWINCH.
2018-05-19 06:38:22 +00:00
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->drawing_area_setup_needed = true;
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 12:44:01 +00:00
}
Further fiddlings with the size reconfiguration stuff; now everything seems to work right even when the only thing changed was the window border. [originally from svn r3109]
2003-04-12 11:03:44 +00:00
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
#if GTK_CHECK_VERSION(3,10,0)
new_scale = gtk_widget_get_scale_factor(inst->area);
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
if (new_scale != inst->scale)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->drawing_area_setup_needed = true;
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
#else
new_scale = 1;
#endif
GTK: fix junk in window margin with fixed-size windows. When the window can't be resized for any reason, there will be extra space inside the drawing area that's not part of our standard width*font_width+2*window_border. We should include that in the backing surface and make sure we erase it to the background colour, otherwise it can end up containing unwanted visual junk. An example is the same case described in the previous commit: maximise the window and then start playing about with the font size. If you do this while running a full-screen application that displays text in the bottom line, it's easy to see that part of the previous display is left over and not cleared when the new font size leaves more space at the bottom than the old one.
2022-02-03 17:56:38 +00:00
int new_backing_w = width * new_scale;
int new_backing_h = height * new_scale;
GTK: Refresh backing surface when border is reconfigured. If you go to Change Settings in Unix PuTTY or pterm, and change the 'Gap between text and window edge' setting but not the width and height, then change_settings_menuitem() correctly sets the physical window to a new size, but drawing_area_setup() was not recreating the backing surface / pixmap in the same way, because it hadn't spotted that the border size might be relevant. Now I unconditionally work out what the exact size of the backing surface _ought_ to be, before reaching the potential early exit path, and never take the early exit if the backing area needs resizing for any reason at all. (I think this probably ought to have been part of commit 528513dde.)
2019-10-20 17:47:04 +00:00
if (inst->backing_w != new_backing_w || inst->backing_h != new_backing_h)
inst->drawing_area_setup_needed = true;
Ignore spurious configure_area events. Colin Watson reports that on pre-releases of Ubuntu 18.04, configure events which don't actually involve a change of window size show up annoyingly often. Our handling of configure events involves throwing away the backing Cairo surface, making a fresh blank one, and scheduling a top-level callback to get terminal.c to do a repaint and populate the new surface; so a draw event before that callback occurs causes the window contents to flicker off and on again, not to mention wasting a lot of time. The simplest solution is to spot spurious configures, and respond by not throwing away the previous Cairo surface in the first place.
2018-04-03 17:57:00 +00:00
/*
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
* GTK will sometimes send us configure events when nothing about
* the window size has actually changed. In some situations this
* can happen quite often, so it's a worthwhile optimisation to
* detect that situation and avoid the expensive reinitialisation
* of the backing surface / image, and so on.
*
* However, we must still communicate to the terminal that we
* received a resize event, because sometimes a trivial resize
* event (to the same size we already were) is a signal from the
* window system that a _nontrivial_ resize we recently asked for
* has failed to happen.
Ignore spurious configure_area events. Colin Watson reports that on pre-releases of Ubuntu 18.04, configure events which don't actually involve a change of window size show up annoyingly often. Our handling of configure events involves throwing away the backing Cairo surface, making a fresh blank one, and scheduling a top-level callback to get terminal.c to do a repaint and populate the new surface; so a draw event before that callback occurs causes the window contents to flicker off and on again, not to mention wasting a lot of time. The simplest solution is to spot spurious configures, and respond by not throwing away the previous Cairo surface in the first place.
2018-04-03 17:57:00 +00:00
*/
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
inst->drawing_area_setup_called = true;
if (inst->term)
term_size(inst->term, h, w, conf_get_int(inst->conf, CONF_savelines));
Fix duplicate call to term_resize_request_completed(). A KDE user observed that if you 'dock' a GTK PuTTY window to the side of the screen (by dragging it to the RH edge, causing it to half-maximise over the right-hand half of the display, similarly to Windows), and then send a terminal resize sequence, then PuTTY fails the assertion in term_resize_request_completed() which expects that an unacknowledged resize request was currently in flight. When drawing_area_setup() calls term_resize_request_completed() in response to the inst->term_resize_notification_required flag, it resets the inst->win_resize_pending flag, but doesn't reset inst->term_resize_notification_required. As a result, the _next_ call to drawing_area_setup will find that flag still set, and make a duplicate call to term_resize_request_completed, after the terminal no longer believes it's waiting for a response to a resize request. And in this 'docked to the right-hand side of the display' state, KDE apparently triggers two calls to drawing_area_setup() in quick succession, making this bug manifest. I could fix this by clearing inst->term_resize_notification_required. But inspecting all the other call sites, it seems clear to me that my original intention was for inst->term_resize_notification_required to be a flag that's only meaningful if inst->win_resize_pending is set. So I think a better fix is to conditionalise the check in drawing_area_setup so that we don't even check inst->term_resize_notification_required if !inst->win_resize_pending.
2022-11-14 22:21:49 +00:00
if (inst->win_resize_pending) {
if (inst->term_resize_notification_required)
term_resize_request_completed(inst->term);
Move window resize timeouts into the GTK frontend. In the changes around commit 420fe75552afa94, I made the terminal suspend output processing while it waited for a term_size() callback in response to a resize request. Because on X11 there are unusual circumstances in which you never receive that callback, I also added a last-ditch 5-second timeout, so that eventually we'll resume terminal output processing regardless. But the timeout lives in terminal.c, in the cross-platform code. This is pointless on Windows (where resize processing is synchronous, so we always finish it before the timer code next gets called anyway), but I decided it was easier to keep the whole mechanism in terminal.c in the absence of a good reason not to. Now I've found that reason. We _also_ generate window resizes locally to the GTK front end, in response to the key combinations that change the font size, and _those_ still have an asynchrony problem. So, to begin with, I'm refactoring the request_resize system so that now there's an explicit callback from the frontend to the terminal to say 'Your resize request has now been processed, whether or not you've received a term_size() call'. On Windows, this simplifies matters greatly because we always know exactly when to call that, and don't have to keep a 'have we called term_size() already?' flag. On GTK, the timing complexity previously in terminal.c has moved into window.c. No functional change (I hope). The payoff will be in the next commit.
2022-05-12 17:16:56 +00:00
inst->win_resize_pending = false;
Fix duplicate call to term_resize_request_completed(). A KDE user observed that if you 'dock' a GTK PuTTY window to the side of the screen (by dragging it to the RH edge, causing it to half-maximise over the right-hand half of the display, similarly to Windows), and then send a terminal resize sequence, then PuTTY fails the assertion in term_resize_request_completed() which expects that an unacknowledged resize request was currently in flight. When drawing_area_setup() calls term_resize_request_completed() in response to the inst->term_resize_notification_required flag, it resets the inst->win_resize_pending flag, but doesn't reset inst->term_resize_notification_required. As a result, the _next_ call to drawing_area_setup will find that flag still set, and make a duplicate call to term_resize_request_completed, after the terminal no longer believes it's waiting for a response to a resize request. And in this 'docked to the right-hand side of the display' state, KDE apparently triggers two calls to drawing_area_setup() in quick succession, making this bug manifest. I could fix this by clearing inst->term_resize_notification_required. But inspecting all the other call sites, it seems clear to me that my original intention was for inst->term_resize_notification_required to be a flag that's only meaningful if inst->win_resize_pending is set. So I think a better fix is to conditionalise the check in drawing_area_setup so that we don't even check inst->term_resize_notification_required if !inst->win_resize_pending.
2022-11-14 22:21:49 +00:00
}
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
if (!inst->drawing_area_setup_needed)
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
return;
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->drawing_area_setup_needed = false;
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
inst->scale = new_scale;
GTK: Refresh backing surface when border is reconfigured. If you go to Change Settings in Unix PuTTY or pterm, and change the 'Gap between text and window edge' setting but not the width and height, then change_settings_menuitem() correctly sets the physical window to a new size, but drawing_area_setup() was not recreating the backing surface / pixmap in the same way, because it hadn't spotted that the border size might be relevant. Now I unconditionally work out what the exact size of the backing surface _ought_ to be, before reaching the potential early exit path, and never take the early exit if the backing area needs resizing for any reason at all. (I think this probably ought to have been part of commit 528513dde.)
2019-10-20 17:47:04 +00:00
inst->backing_w = new_backing_w;
inst->backing_h = new_backing_h;
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#ifndef NO_BACKING_PIXMAPS
Remove extra braces in drawing_area_setup. (NFC) I'm about to rearrange this function, and the patch that actually does work will be easier to read if mass reindentation isn't combined with it. The braces I've just removed were necessary when we hadn't yet committed to requiring (most of) C99 from all our build platforms. Now they aren't.
2019-10-20 17:47:33 +00:00
if (inst->pixmap) {
gdk_pixmap_unref(inst->pixmap);
inst->pixmap = NULL;
}
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Remove extra braces in drawing_area_setup. (NFC) I'm about to rearrange this function, and the patch that actually does work will be easier to read if mass reindentation isn't combined with it. The braces I've just removed were necessary when we hadn't yet committed to requiring (most of) C99 from all our build platforms. Now they aren't.
2019-10-20 17:47:33 +00:00
inst->pixmap = gdk_pixmap_new(gtk_widget_get_window(inst->area),
GTK: Refresh backing surface when border is reconfigured. If you go to Change Settings in Unix PuTTY or pterm, and change the 'Gap between text and window edge' setting but not the width and height, then change_settings_menuitem() correctly sets the physical window to a new size, but drawing_area_setup() was not recreating the backing surface / pixmap in the same way, because it hadn't spotted that the border size might be relevant. Now I unconditionally work out what the exact size of the backing surface _ought_ to be, before reaching the potential early exit path, and never take the early exit if the backing area needs resizing for any reason at all. (I think this probably ought to have been part of commit 528513dde.)
2019-10-20 17:47:04 +00:00
inst->backing_w, inst->backing_h, -1);
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#endif
Further fiddlings with the size reconfiguration stuff; now everything seems to work right even when the only thing changed was the window border. [originally from svn r3109]
2003-04-12 11:03:44 +00:00
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
#ifdef DRAW_TEXT_CAIRO
Remove extra braces in drawing_area_setup. (NFC) I'm about to rearrange this function, and the patch that actually does work will be easier to read if mass reindentation isn't combined with it. The braces I've just removed were necessary when we hadn't yet committed to requiring (most of) C99 from all our build platforms. Now they aren't.
2019-10-20 17:47:33 +00:00
if (inst->surface) {
cairo_surface_destroy(inst->surface);
inst->surface = NULL;
}
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
GTK: Refresh backing surface when border is reconfigured. If you go to Change Settings in Unix PuTTY or pterm, and change the 'Gap between text and window edge' setting but not the width and height, then change_settings_menuitem() correctly sets the physical window to a new size, but drawing_area_setup() was not recreating the backing surface / pixmap in the same way, because it hadn't spotted that the border size might be relevant. Now I unconditionally work out what the exact size of the backing surface _ought_ to be, before reaching the potential early exit path, and never take the early exit if the backing area needs resizing for any reason at all. (I think this probably ought to have been part of commit 528513dde.)
2019-10-20 17:47:04 +00:00
inst->surface = cairo_image_surface_create(
CAIRO_FORMAT_ARGB32, inst->backing_w, inst->backing_h);
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
#endif
Debian bug #193013 points out that the (default-)one-pixel border is not redrawn when the window background colour is reconfigured mid- session. In addition, the Official Window Background is not reset, meaning that opaque resizes etc will flicker in the old background colour. This checkin should fix both. [originally from svn r3190]
2003-05-13 18:14:14 +00:00
draw_backing_rect(inst);
Further fiddlings with the size reconfiguration stuff; now everything seems to work right even when the only thing changed was the window border. [originally from svn r3109]
2003-04-12 11:03:44 +00:00
if (inst->term)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_invalidate(inst->term);
Further fiddlings with the size reconfiguration stuff; now everything seems to work right even when the only thing changed was the window border. [originally from svn r3109]
2003-04-12 11:03:44 +00:00
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
gtk_im_context_set_client_window(
inst->imc, gtk_widget_get_window(inst->area));
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#endif
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
}
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void drawing_area_setup_simple(GtkFrontend *inst)
gtkwin: factor out drawing_area_setup_simple(). I'm about to want to do this operation from more places, so here's a minor NFC refactoring that will simplify the next commit.
2018-05-11 08:00:46 +00:00
{
/*
* Wrapper on drawing_area_setup which fetches the width and
* height of the drawing area. We go directly to the inner version
* in the case where a new size allocation comes in (just in case
* GTK hasn't installed it in the normal place yet).
*/
#if GTK_CHECK_VERSION(2,0,0)
GdkRectangle alloc;
gtk_widget_get_allocation(inst->area, &alloc);
#else
GtkAllocation alloc = inst->area->allocation;
#endif
drawing_area_setup(inst, alloc.width, alloc.height);
}
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
static void drawing_area_setup_cb(void *vctx)
{
GtkFrontend *inst = (GtkFrontend *)vctx;
if (!inst->drawing_area_setup_called)
drawing_area_setup_simple(inst);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void area_realised(GtkWidget *widget, GtkFrontend *inst)
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->drawing_area_realised = true;
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
if (inst->drawing_area_realised && inst->drawing_area_got_size &&
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
inst->drawing_area_setup_needed)
gtkwin: factor out drawing_area_setup_simple(). I'm about to want to do this operation from more places, so here's a minor NFC refactoring that will simplify the next commit.
2018-05-11 08:00:46 +00:00
drawing_area_setup_simple(inst);
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
}
static void area_size_allocate(
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkWidget *widget, GdkRectangle *alloc, GtkFrontend *inst)
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->drawing_area_got_size = true;
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
if (inst->drawing_area_realised && inst->drawing_area_got_size)
drawing_area_setup(inst, alloc->width, alloc->height);
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
}
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
#if GTK_CHECK_VERSION(3,10,0)
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void area_check_scale(GtkFrontend *inst)
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
{
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
if (!inst->drawing_area_setup_needed &&
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
inst->scale != gtk_widget_get_scale_factor(inst->area)) {
drawing_area_setup_simple(inst);
if (inst->term) {
term_invalidate(inst->term);
term_update(inst->term);
}
}
}
#endif
Flip direction of window pos/size queries. Similarly to other recent changes, the frontend now proactively keeps Terminal up to date with the current position and size of the terminal window, so that escape-sequence queries can be answered immediately from the Terminal's own internal data structures without needing a call back to the frontend. Mostly this has let me remove explicit window-system API calls that retrieve the window position and size, in favour of having the front ends listen for WM_MOVE / WM_SIZE / ConfigureNotify events and track the position and size that way. One exception is that the window pixel size is still requested by Seat via a callback, to put in the wire-encoded termios settings. That won't be happening very much, so I'm leaving it this way round for the moment.
2021-02-07 19:59:21 +00:00
static gboolean window_configured(
GtkWidget *widget, GdkEventConfigure *event, gpointer data)
{
GtkFrontend *inst = (GtkFrontend *)data;
if (inst->term) {
term_notify_window_pos(inst->term, event->x, event->y);
term_notify_window_size_pixels(
inst->term, event->width, event->height);
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
if (inst->drawing_area_realised && inst->drawing_area_got_size) {
inst->drawing_area_setup_called = false;
queue_toplevel_callback(drawing_area_setup_cb, inst);
}
Flip direction of window pos/size queries. Similarly to other recent changes, the frontend now proactively keeps Terminal up to date with the current position and size of the terminal window, so that escape-sequence queries can be answered immediately from the Terminal's own internal data structures without needing a call back to the frontend. Mostly this has let me remove explicit window-system API calls that retrieve the window position and size, in favour of having the front ends listen for WM_MOVE / WM_SIZE / ConfigureNotify events and track the position and size that way. One exception is that the window pixel size is still requested by Seat via a callback, to put in the wire-encoded termios settings. That won't be happening very much, so I'm leaving it this way round for the moment.
2021-02-07 19:59:21 +00:00
}
return false;
}
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
#if GTK_CHECK_VERSION(3,10,0)
static gboolean area_configured(
GtkWidget *widget, GdkEventConfigure *event, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
area_check_scale(inst);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
}
#endif
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void cairo_setup_draw_ctx(GtkFrontend *inst)
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
cairo_get_matrix(inst->uctx.u.cairo.cr,
&inst->uctx.u.cairo.origmatrix);
cairo_set_line_width(inst->uctx.u.cairo.cr, 1.0);
cairo_set_line_cap(inst->uctx.u.cairo.cr, CAIRO_LINE_CAP_SQUARE);
cairo_set_line_join(inst->uctx.u.cairo.cr, CAIRO_LINE_JOIN_MITER);
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
/* This antialiasing setting appears to be ignored for Pango
* font rendering but honoured for stroking and filling paths;
* I don't quite understand the logic of that, but I won't
* complain since it's exactly what I happen to want */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
cairo_set_antialias(inst->uctx.u.cairo.cr, CAIRO_ANTIALIAS_NONE);
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
}
#endif
#if GTK_CHECK_VERSION(3,0,0)
static gint draw_area(GtkWidget *widget, cairo_t *cr, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
#if GTK_CHECK_VERSION(3,10,0)
/*
* This may be the first we hear of the window scale having
* changed, in which case we must hastily reconstruct our backing
* surface before we copy the wrong one into the newly resized
* real window.
*/
area_check_scale(inst);
#endif
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
/*
* GTK3 window redraw: we always expect Cairo to be enabled, so
* that inst->surface exists, and pixmaps to be disabled, so that
* inst->pixmap does not exist. Hence, we just blit from
* inst->surface to the window.
*/
if (inst->surface) {
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
GdkRectangle dirtyrect;
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
cairo_surface_t *target_surface;
double orig_sx, orig_sy;
cairo_matrix_t m;
/*
* Furtle around in the Cairo setup to force the device scale
* back to 1, so that when we blit a collection of pixels from
* our backing surface into the window, they really are
* _pixels_ and not some confusing antialiased slightly-offset
* 2x2 rectangle of pixeloids.
*
* I have no idea whether GTK expects me not to mess with the
* device scale in the cairo_surface_t backing its window, so
* I carefully put it back when I've finished.
*
* In some GTK setups, the Cairo context we're given may not
* have a zero translation offset in its matrix, in which case
* we have to adjust that to compensate for the change of
* scale, or else the old translation offset (designed for the
* old scale) will be multiplied by the new scale instead and
* put everything in the wrong place.
*/
target_surface = cairo_get_target(cr);
cairo_get_matrix(cr, &m);
cairo_surface_get_device_scale(target_surface, &orig_sx, &orig_sy);
cairo_surface_set_device_scale(target_surface, 1.0, 1.0);
cairo_translate(cr, m.x0 * (orig_sx - 1.0), m.y0 * (orig_sy - 1.0));
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
gdk_cairo_get_clip_rectangle(cr, &dirtyrect);
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
cairo_set_source_surface(cr, inst->surface, 0, 0);
cairo_rectangle(cr, dirtyrect.x, dirtyrect.y,
dirtyrect.width, dirtyrect.height);
cairo_fill(cr);
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
cairo_surface_set_device_scale(target_surface, orig_sx, orig_sy);
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
}
#else
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
gint expose_area(GtkWidget *widget, GdkEventExpose *event, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#ifndef NO_BACKING_PIXMAPS
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
/*
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
* Draw to the exposed part of the window from the server-side
* backing pixmap.
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
*/
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
if (inst->pixmap) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gdk_draw_pixmap(gtk_widget_get_window(widget),
(gtk_widget_get_style(widget)->fg_gc
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
[gtk_widget_get_state(widget)]),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->pixmap,
event->area.x, event->area.y,
event->area.x, event->area.y,
event->area.width, event->area.height);
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
}
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#else
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
/*
* Failing that, draw from the client-side Cairo surface. (We
* should never be compiled in a context where we have _neither_
* inst->surface nor inst->pixmap.)
*/
if (inst->surface) {
cairo_t *cr = gdk_cairo_create(gtk_widget_get_window(widget));
cairo_set_source_surface(cr, inst->surface, 0, 0);
cairo_rectangle(cr, event->area.x, event->area.y,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
event->area.width, event->area.height);
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
cairo_fill(cr);
cairo_destroy(cr);
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
}
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
}
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#endif
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
#define KEY_PRESSED(k) \
(inst->keystate[(k) / 32] & (1 << ((k) % 32)))
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *dup_keyval_name(guint keyval)
{
const char *name = gdk_keyval_name(keyval);
if (name)
return dupstr(name);
else
return dupprintf("UNKNOWN[%u]", (unsigned)keyval);
}
#endif
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void change_font_size(GtkFrontend *inst, int increment);
static void key_pressed(GtkFrontend *inst);
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
Fix handling of Return and keypad Enter. The recent rewriting in both the GTK and Windows keyboard handlers left the keypad 'Enter' key in a bad state, when no override is enabled that causes it to generate an escape sequence. On Windows, a series of fallbacks was causing it to generate \r regardless of configuration, whereas in Telnet mode it should default to generating the special Telnet new-line sequence, and in response to ESC[20h (enabling term->cr_lf_return) it should generate \r\n. On GTK, it wasn't generating anything _at all_, and also, I can't see any evidence that the GTK keyboard handler had ever remembered to implement the cr_lf_return mode. Now Keypad Enter in non-escape-sequence mode should behave just like Return, on both platforms.
2019-04-15 19:43:10 +00:00
/* Subroutine used in key_event */
static int return_key(GtkFrontend *inst, char *output, bool *special)
{
int end;
/* Ugly label so we can come here as a fallback from
* numeric keypad Enter handling */
if (inst->term->cr_lf_return) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug(" - Return in cr_lf_return mode, translating as 0d 0a\n");
#endif
output[1] = '\015';
output[2] = '\012';
end = 3;
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
debug(" - Return special case, translating as 0d + special\n");
#endif
output[1] = '\015';
end = 2;
*special = true;
}
return end;
}
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
gint key_event(GtkWidget *widget, GdkEventKey *event, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Debian bug #517535: we were unconditionally interpreting the '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]
2009-02-28 16:52:42 +00:00
char output[256];
Support for non-ISO-8859-1 X keysyms. So in particular, pterm in a Euro-supporting font with a Euro-enabled X key map will now actually generate a Euro character rather than shrugging and doing nothing. [originally from svn r3151]
2003-04-27 11:10:48 +00:00
wchar_t ucsoutput[2];
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int ucsval, start, end, output_charset;
bool special, use_ucsoutput;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
bool force_format_numeric_keypad = false;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
bool generated_something = false;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
char num_keypad_key = '\0';
Cope with a GdkEventKey having a NULL string field. When you run using the GDK Broadway backend, this turns out to happen, and it's new in my experience - I was cheerfully iterating over event->string and calling strlen on it without ever checking it for NULL.
2020-11-24 20:37:47 +00:00
const char *event_string = event->string ? event->string : "";
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Label random-noise sources with an enum of ids. The upcoming PRNG revamp will want to tell noise sources apart, so that it can treat them all fairly. So I've added an extra parameter to noise_ultralight and random_add_noise, which takes values in an enumeration covering all the vague classes of entropy source I'm collecting. In this commit, though, it's simply ignored.
2019-01-22 18:25:54 +00:00
noise_ultralight(NOISE_SOURCE_KEY, event->keyval);
Add more random-number noise collection calls. Mostly on the Unix side: there are lots of places the Windows code was collecting noise that the corresponding Unix/GTK code wasn't bothering to, such as mouse movements, keystrokes and various network events. Also, both platforms had forgotten to collect noise when reading data from a pipe to a local proxy process, even though in that configuration that's morally equivalent to the network packet timings that we'd normally be collecting from.
2019-01-22 21:01:26 +00:00
OS X: pass Command key back to GTK if it's not being Meta. This fixes the problem I'd previously noticed, that if you don't configure the "Command key acts as Meta" setting, then keystrokes like Command-Q which _ought_ to function as accelerators for the application menu bar don't. Turns out that this was for the totally obvious reason: the keyboard event was still being processed by gtkwin.c's key_event() and translated via the GTK IM into ordinary keyboard input. If instead I return FALSE from key_event on detecting that a key event has a non-Meta-configured Command modifier, then it will go to the next- level key-event handler inside GTK itself which implements the menu accelerator behaviour. Another problem ticked off the OS X checklist.
2017-12-18 10:43:13 +00:00
#ifdef OSX_META_KEY_CONFIG
if (event->state & inst->system_mod_mask)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false; /* let GTK process OS X Command key */
OS X: pass Command key back to GTK if it's not being Meta. This fixes the problem I'd previously noticed, that if you don't configure the "Command key acts as Meta" setting, then keystrokes like Command-Q which _ought_ to function as accelerators for the application menu bar don't. Turns out that this was for the totally obvious reason: the keyboard event was still being processed by gtkwin.c's key_event() and translated via the GTK IM into ordinary keyboard input. If instead I return FALSE from key_event on detecting that a key event has a non-Meta-configured Command modifier, then it will go to the next- level key-event handler inside GTK itself which implements the menu accelerator behaviour. Another problem ticked off the OS X checklist.
2017-12-18 10:43:13 +00:00
#endif
Richard Boulton's patch for improved correctness in selection handling (generally, selection request timestamps should be set to the timestamp on the event that caused them). [originally from svn r3408]
2003-08-21 18:03:06 +00:00
/* Remember the timestamp. */
inst->input_event_time = event->time;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
/* By default, nothing is generated. */
end = start = 0;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
special = use_ucsoutput = false;
Debian bug #517535: we were unconditionally interpreting the '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]
2009-02-28 16:52:42 +00:00
output_charset = CS_ISO8859_1;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
Add conditioned-out diagnostics in GTK key_event(). 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"
2015-08-27 17:35:17 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
{
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
char *type_string, *state_string, *keyval_string, *string_string;
type_string = (event->type == GDK_KEY_PRESS ? dupstr("PRESS") :
event->type == GDK_KEY_RELEASE ? dupstr("RELEASE") :
dupprintf("UNKNOWN[%d]", (int)event->type));
{
static const struct {
int mod_bit;
const char *name;
} mod_bits[] = {
{GDK_SHIFT_MASK, "SHIFT"},
{GDK_LOCK_MASK, "LOCK"},
{GDK_CONTROL_MASK, "CONTROL"},
{GDK_MOD1_MASK, "MOD1"},
{GDK_MOD2_MASK, "MOD2"},
{GDK_MOD3_MASK, "MOD3"},
{GDK_MOD4_MASK, "MOD4"},
{GDK_MOD5_MASK, "MOD5"},
{GDK_SUPER_MASK, "SUPER"},
{GDK_HYPER_MASK, "HYPER"},
{GDK_META_MASK, "META"},
};
int i;
int val = event->state;
state_string = dupstr("");
for (i = 0; i < lenof(mod_bits); i++) {
if (val & mod_bits[i].mod_bit) {
char *old = state_string;
state_string = dupcat(state_string,
state_string[0] ? "|" : "",
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
mod_bits[i].name);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(old);
val &= ~mod_bits[i].mod_bit;
}
}
if (val || !state_string[0]) {
char *old = state_string;
state_string = dupprintf("%s%s%d", state_string,
state_string[0] ? "|" : "", val);
sfree(old);
}
}
keyval_string = dup_keyval_name(event->keyval);
string_string = dupstr("");
{
int i;
Cope with a GdkEventKey having a NULL string field. When you run using the GDK Broadway backend, this turns out to happen, and it's new in my experience - I was cheerfully iterating over event->string and calling strlen on it without ever checking it for NULL.
2020-11-24 20:37:47 +00:00
for (i = 0; event_string[i]; i++) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
Cope with a GdkEventKey having a NULL string field. When you run using the GDK Broadway backend, this turns out to happen, and it's new in my experience - I was cheerfully iterating over event->string and calling strlen on it without ever checking it for NULL.
2020-11-24 20:37:47 +00:00
(unsigned)event_string[i] & 0xFF);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(old);
}
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug("key_event: type=%s keyval=%s state=%s "
"hardware_keycode=%d is_modifier=%s string=[%s]\n",
type_string, keyval_string, state_string,
(int)event->hardware_keycode,
event->is_modifier ? "true" : "false",
string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(type_string);
sfree(state_string);
sfree(keyval_string);
sfree(string_string);
Add conditioned-out diagnostics in GTK key_event(). 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"
2015-08-27 17:35:17 +00:00
}
#endif /* KEY_EVENT_DIAGNOSTICS */
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
/*
* If Alt is being released after typing an Alt+numberpad
* sequence, we should generate the code that was typed.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Fix Alt+numberpad in pterm. For a start, there was a bug whereby if 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]
2002-10-28 17:34:45 +00:00
* Note that we only do this if more than one key was actually
* pressed - I don't think Alt+NumPad4 should be ^D or that
* Alt+NumPad3 should be ^C, for example. There's no serious
* inconvenience in having to type a zero before a single-digit
* character code.
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
*/
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
if (event->type == GDK_KEY_RELEASE) {
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
if ((event->keyval == GDK_KEY_Meta_L ||
event->keyval == GDK_KEY_Meta_R ||
event->keyval == GDK_KEY_Alt_L ||
event->keyval == GDK_KEY_Alt_R) &&
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
inst->alt_keycode >= 0 && inst->alt_digits > 1) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - modifier release terminates Alt+numberpad input, "
"keycode = %d\n", inst->alt_keycode);
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#endif
/*
* FIXME: we might usefully try to do something clever here
* about interpreting the generated key code in a way that's
* appropriate to the line code page.
*/
output[0] = inst->alt_keycode;
end = 1;
goto done;
}
#if GTK_CHECK_VERSION(2,0,0)
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - key release, passing to IM\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
if (gtk_im_context_filter_keypress(inst->imc, event)) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - key release accepted by IM\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - key release not accepted by IM\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
}
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
#endif
}
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
if (event->type == GDK_KEY_PRESS) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* If Alt has just been pressed, we start potentially
* accumulating an Alt+numberpad code. We do this by
* setting alt_keycode to -1 (nothing yet but plausible).
*/
if ((event->keyval == GDK_KEY_Meta_L ||
event->keyval == GDK_KEY_Meta_R ||
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
event->keyval == GDK_KEY_Alt_L ||
event->keyval == GDK_KEY_Alt_R)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - modifier press potentially begins Alt+numberpad "
"input\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->alt_keycode = -1;
Fix Alt+numberpad in pterm. For a start, there was a bug whereby if 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]
2002-10-28 17:34:45 +00:00
inst->alt_digits = 0;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
goto done; /* this generates nothing else */
}
/*
* If we're seeing a numberpad key press with Meta down,
* consider adding it to alt_keycode if that's sensible.
* Anything _else_ with Meta down cancels any possibility
* of an ALT keycode: we set alt_keycode to -2.
*/
if ((event->state & inst->meta_mod_mask) && inst->alt_keycode != -2) {
int digit = -1;
switch (event->keyval) {
case GDK_KEY_KP_0: case GDK_KEY_KP_Insert: digit = 0; break;
case GDK_KEY_KP_1: case GDK_KEY_KP_End: digit = 1; break;
case GDK_KEY_KP_2: case GDK_KEY_KP_Down: digit = 2; break;
case GDK_KEY_KP_3: case GDK_KEY_KP_Page_Down: digit = 3; break;
case GDK_KEY_KP_4: case GDK_KEY_KP_Left: digit = 4; break;
case GDK_KEY_KP_5: case GDK_KEY_KP_Begin: digit = 5; break;
case GDK_KEY_KP_6: case GDK_KEY_KP_Right: digit = 6; break;
case GDK_KEY_KP_7: case GDK_KEY_KP_Home: digit = 7; break;
case GDK_KEY_KP_8: case GDK_KEY_KP_Up: digit = 8; break;
case GDK_KEY_KP_9: case GDK_KEY_KP_Page_Up: digit = 9; break;
}
if (digit < 0)
inst->alt_keycode = -2; /* it's invalid */
else {
gtkwin: solved unused variable error solved unused variable error when KEY_EVENT_DIAGNOSTICS defined but DEBUG not defined although we intend to always define DEBUG when KEY_EVENT_DIAGNOSTICS is going to be defined.
2021-01-11 02:55:56 +00:00
#if defined(DEBUG) && defined(KEY_EVENT_DIAGNOSTICS)
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
int old_keycode = inst->alt_keycode;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (inst->alt_keycode == -1)
inst->alt_keycode = digit; /* one-digit code */
else
inst->alt_keycode = inst->alt_keycode * 10 + digit;
Fix Alt+numberpad in pterm. For a start, there was a bug whereby if 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]
2002-10-28 17:34:45 +00:00
inst->alt_digits++;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Alt+numberpad digit %d added to keycode %d"
" gives %d\n", digit, old_keycode, inst->alt_keycode);
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Having used this digit, we now do nothing more with it. */
goto done;
}
}
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
if (event->keyval == GDK_KEY_greater &&
(event->state & GDK_CONTROL_MASK)) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl->: increase font size\n");
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
#endif
GTK: don't try to change font size in mid-window-resize. If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
2022-05-12 18:38:45 +00:00
if (!inst->win_resize_pending)
change_font_size(inst, +1);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
}
if (event->keyval == GDK_KEY_less &&
(event->state & GDK_CONTROL_MASK)) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-<: increase font size\n");
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
#endif
GTK: don't try to change font size in mid-window-resize. If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
2022-05-12 18:38:45 +00:00
if (!inst->win_resize_pending)
change_font_size(inst, -1);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Shift-PgUp and Shift-PgDn don't even generate keystrokes
* at all.
*/
ctrl-shift-page-up/down to top or bottom of scrollback Just a small patch, that I find really useful.
2017-11-03 14:31:10 +00:00
if (event->keyval == GDK_KEY_Page_Up &&
((event->state & (GDK_CONTROL_MASK | GDK_SHIFT_MASK)) ==
(GDK_CONTROL_MASK | GDK_SHIFT_MASK))) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-PgUp scroll\n");
ctrl-shift-page-up/down to top or bottom of scrollback Just a small patch, that I find really useful.
2017-11-03 14:31:10 +00:00
#endif
term_scroll(inst->term, 1, 0);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
ctrl-shift-page-up/down to top or bottom of scrollback Just a small patch, that I find really useful.
2017-11-03 14:31:10 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (event->keyval == GDK_KEY_Page_Up &&
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
(event->state & GDK_SHIFT_MASK)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-PgUp scroll\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_scroll(inst->term, 0, -inst->height/2);
return true;
}
if (event->keyval == GDK_KEY_Page_Up &&
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
(event->state & GDK_CONTROL_MASK)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-PgUp scroll\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_scroll(inst->term, 0, -1);
return true;
}
ctrl-shift-page-up/down to top or bottom of scrollback Just a small patch, that I find really useful.
2017-11-03 14:31:10 +00:00
if (event->keyval == GDK_KEY_Page_Down &&
((event->state & (GDK_CONTROL_MASK | GDK_SHIFT_MASK)) ==
(GDK_CONTROL_MASK | GDK_SHIFT_MASK))) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-shift-PgDn scroll\n");
ctrl-shift-page-up/down to top or bottom of scrollback Just a small patch, that I find really useful.
2017-11-03 14:31:10 +00:00
#endif
term_scroll(inst->term, -1, 0);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
ctrl-shift-page-up/down to top or bottom of scrollback Just a small patch, that I find really useful.
2017-11-03 14:31:10 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (event->keyval == GDK_KEY_Page_Down &&
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
(event->state & GDK_SHIFT_MASK)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-PgDn scroll\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_scroll(inst->term, 0, +inst->height/2);
return true;
}
if (event->keyval == GDK_KEY_Page_Down &&
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
(event->state & GDK_CONTROL_MASK)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-PgDn scroll\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_scroll(inst->term, 0, +1);
return true;
}
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Neither do Shift-Ins or Ctrl-Ins (if enabled).
*/
if (event->keyval == GDK_KEY_Insert &&
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
(event->state & GDK_SHIFT_MASK)) {
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
int cfgval = conf_get_int(inst->conf, CONF_ctrlshiftins);
switch (cfgval) {
case CLIPUI_IMPLICIT:
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-Insert: paste from PRIMARY\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
term_request_paste(inst->term, CLIP_PRIMARY);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
case CLIPUI_EXPLICIT:
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-Insert: paste from CLIPBOARD\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
term_request_paste(inst->term, CLIP_CLIPBOARD);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
case CLIPUI_CUSTOM:
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-Insert: paste from custom clipboard\n");
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
#endif
term_request_paste(inst->term, inst->clipboard_ctrlshiftins);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
default:
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-Insert: no paste action\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
break;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
if (event->keyval == GDK_KEY_Insert &&
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
(event->state & GDK_CONTROL_MASK)) {
static const int clips_clipboard[] = { CLIP_CLIPBOARD };
int cfgval = conf_get_int(inst->conf, CONF_ctrlshiftins);
switch (cfgval) {
case CLIPUI_IMPLICIT:
/* do nothing; re-copy to PRIMARY is not needed */
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Insert: non-copy to PRIMARY\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
case CLIPUI_EXPLICIT:
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Insert: copy to CLIPBOARD\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
term_request_copy(inst->term,
clips_clipboard, lenof(clips_clipboard));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
case CLIPUI_CUSTOM:
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Insert: copy to custom clipboard\n");
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
#endif
term_request_copy(inst->term,
&inst->clipboard_ctrlshiftins, 1);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
default:
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Insert: no copy action\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
break;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
/*
* Another pair of copy-paste keys.
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((event->state & GDK_SHIFT_MASK) &&
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
(event->state & GDK_CONTROL_MASK) &&
(event->keyval == GDK_KEY_C || event->keyval == GDK_KEY_c ||
event->keyval == GDK_KEY_V || event->keyval == GDK_KEY_v)) {
int cfgval = conf_get_int(inst->conf, CONF_ctrlshiftcv);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool paste = (event->keyval == GDK_KEY_V ||
event->keyval == GDK_KEY_v);
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
switch (cfgval) {
case CLIPUI_IMPLICIT:
if (paste) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-V: paste from PRIMARY\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
term_request_paste(inst->term, CLIP_PRIMARY);
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-C: non-copy to PRIMARY\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
case CLIPUI_EXPLICIT:
if (paste) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-V: paste from CLIPBOARD\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
term_request_paste(inst->term, CLIP_CLIPBOARD);
} else {
static const int clips[] = { CLIP_CLIPBOARD };
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-C: copy to CLIPBOARD\n");
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#endif
term_request_copy(inst->term, clips, lenof(clips));
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
case CLIPUI_CUSTOM:
if (paste) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-V: paste from custom clipboard\n");
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
#endif
term_request_paste(inst->term,
inst->clipboard_ctrlshiftcv);
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-C: copy to custom clipboard\n");
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
#endif
term_request_copy(inst->term,
&inst->clipboard_ctrlshiftcv, 1);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Shift-Ins pastes. [originally from svn r2034]
2002-10-13 11:27:39 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
special = false;
use_ucsoutput = false;
Implement the ldisc `special' mechanism in Unix, without which local line editing didn't work at all. [originally from svn r3107]
2003-04-12 09:27:56 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* ALT+things gives leading Escape. */
output[0] = '\033';
Debian bug #517535: we were unconditionally interpreting the '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]
2009-02-28 16:52:42 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* In vanilla X, and hence also GDK 1.2, the string received
* as part of a keyboard event is assumed to be in
* ISO-8859-1. (Seems woefully shortsighted in i18n terms,
* but it's true: see the man page for XLookupString(3) for
* confirmation.)
*/
output_charset = CS_ISO8859_1;
Cope with a GdkEventKey having a NULL string field. When you run using the GDK Broadway backend, this turns out to happen, and it's new in my experience - I was cheerfully iterating over event->string and calling strlen on it without ever checking it for NULL.
2020-11-24 20:37:47 +00:00
strncpy(output+1, event_string, lenof(output)-1);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#else /* !GTK_CHECK_VERSION(2,0,0) */
Turns out that the compose-keys fix in r9567 did in fact break one 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 == 7fc8db15b262ba644b1c7f8e9b89cc5a86f104f2]
2012-07-05 23:45:20 +00:00
/*
* Most things can now be passed to
* gtk_im_context_filter_keypress without breaking anything
* below this point. An exception is the numeric keypad if
* we're in Nethack or application mode: the IM will eat
* numeric keypad presses if Num Lock is on, but we don't want
* it to.
*/
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
bool numeric = false;
Fix build failures under GTK 1. My previous dodge to make the GTK 1 headers work with modern compilers was to manually reset to -std=gnu89, which changed the semantics of 'inline' back to what glib.h was expecting. But that doesn't work now the PuTTY code base expects to be able to use the rest of C99, so instead I have to manually override the specific #defines that glib.h uses to know how 'inline' works. Also, moved that code in configure.ac out of the fallback branch that manually detects GTK1, so that it will fire even if autoconf is run on a system that still has the genuine GTK1 detection code. (Amazingly, one still exists that I have access to!) With that fixed, there's one more problem: the nethack_mode and app_keypad_mode flags in gtkwin.c's key_event() are only used in the GTK >= 2 branch of the ifdefs, so they should only be declared and set in that branch as well, on pain of a -Wunused complaint.
2019-03-12 07:52:52 +00:00
bool nethack_mode = conf_get_bool(inst->conf, CONF_nethack_keypad);
bool app_keypad_mode = (inst->term->app_keypad_keys &&
!conf_get_bool(inst->conf, CONF_no_applic_k));
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
switch (event->keyval) {
case GDK_KEY_Num_Lock: num_keypad_key = 'G'; break;
case GDK_KEY_KP_Divide: num_keypad_key = '/'; break;
case GDK_KEY_KP_Multiply: num_keypad_key = '*'; break;
case GDK_KEY_KP_Subtract: num_keypad_key = '-'; break;
case GDK_KEY_KP_Add: num_keypad_key = '+'; break;
case GDK_KEY_KP_Enter: num_keypad_key = '\r'; break;
case GDK_KEY_KP_0: num_keypad_key = '0'; numeric = true; break;
case GDK_KEY_KP_Insert: num_keypad_key = '0'; break;
case GDK_KEY_KP_1: num_keypad_key = '1'; numeric = true; break;
case GDK_KEY_KP_End: num_keypad_key = '1'; break;
case GDK_KEY_KP_2: num_keypad_key = '2'; numeric = true; break;
case GDK_KEY_KP_Down: num_keypad_key = '2'; break;
case GDK_KEY_KP_3: num_keypad_key = '3'; numeric = true; break;
case GDK_KEY_KP_Page_Down: num_keypad_key = '3'; break;
case GDK_KEY_KP_4: num_keypad_key = '4'; numeric = true; break;
case GDK_KEY_KP_Left: num_keypad_key = '4'; break;
case GDK_KEY_KP_5: num_keypad_key = '5'; numeric = true; break;
case GDK_KEY_KP_Begin: num_keypad_key = '5'; break;
case GDK_KEY_KP_6: num_keypad_key = '6'; numeric = true; break;
case GDK_KEY_KP_Right: num_keypad_key = '6'; break;
case GDK_KEY_KP_7: num_keypad_key = '7'; numeric = true; break;
case GDK_KEY_KP_Home: num_keypad_key = '7'; break;
case GDK_KEY_KP_8: num_keypad_key = '8'; numeric = true; break;
case GDK_KEY_KP_Up: num_keypad_key = '8'; break;
case GDK_KEY_KP_9: num_keypad_key = '9'; numeric = true; break;
case GDK_KEY_KP_Page_Up: num_keypad_key = '9'; break;
case GDK_KEY_KP_Decimal: num_keypad_key = '.'; numeric = true; break;
case GDK_KEY_KP_Delete: num_keypad_key = '.'; break;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((app_keypad_mode && num_keypad_key &&
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
(numeric || inst->term->funky_type != FUNKY_XTERM)) ||
(nethack_mode && num_keypad_key >= '1' && num_keypad_key <= '9')) {
/* In these modes, we override the keypad handling:
* regardless of Num Lock, the keys are handled by
* format_numeric_keypad_key below. */
force_format_numeric_keypad = true;
Turns out that the compose-keys fix in r9567 did in fact break one 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 == 7fc8db15b262ba644b1c7f8e9b89cc5a86f104f2]
2012-07-05 23:45:20 +00:00
} else {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool try_filter = true;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
Work around OS X GTK treating Option as an AltGr key. 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.
2015-09-01 18:10:29 +00:00
#ifdef META_MANUAL_MASK
if (event->state & META_MANUAL_MASK & inst->meta_mod_mask) {
/*
* If this key event had a Meta modifier bit set which
* is also in META_MANUAL_MASK, that means passing
* such an event to the GtkIMContext will be unhelpful
* (it will eat the keystroke and turn it into
* something not what we wanted).
*/
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Meta modifier requiring manual intervention, "
"suppressing IM filtering\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
try_filter = false;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
}
#endif
if (try_filter) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - general key press, passing to IM\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
if (gtk_im_context_filter_keypress(inst->imc, event)) {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - key press accepted by IM\n");
Work around OS X GTK treating Option as an AltGr key. 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.
2015-09-01 18:10:29 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - key press not accepted by IM\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
}
}
Turns out that the compose-keys fix in r9567 did in fact break one 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 == 7fc8db15b262ba644b1c7f8e9b89cc5a86f104f2]
2012-07-05 23:45:20 +00:00
}
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* GDK 2.0 arranges to have done some translation for us: in
* GDK 2.0, event->string is encoded in the current locale.
*
* So we use the standard C library function mbstowcs() to
* convert from the current locale into Unicode; from there
* we can convert to whatever PuTTY is currently working in.
* (In fact I convert straight back to UTF-8 from
* wide-character Unicode, for the sake of simplicity: that
* way we can still use exactly the same code to manipulate
* the string, such as prefixing ESC.)
*/
output_charset = CS_UTF8;
{
wchar_t widedata[32];
Add some missing consts in character set handling. [originally from svn r9291]
2011-09-16 19:18:52 +00:00
const wchar_t *wp;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int wlen;
int ulen;
Rework Unicode conversion APIs to use a BinarySink. The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs. This commit introduces a fresh pair of functions to replace them, which generate output by writing to a BinarySink. So it's now up to the caller to decide whether it wants the output written to a fixed-size buffer with overflow checking (via buffer_sink), or dynamically allocated, or even written directly to some other output channel. Nothing uses the new functions yet. I plan to migrate things over in upcoming commits. What was wrong with the old APIs: they had that awkward undocumented Windows-specific 'flags' parameter that I described in the previous commit and took out of the dup_X_to_Y wrappers. But much worse, the semantics for buffer overflow were not just undocumented but actually inconsistent. dup_wc_to_mb() in utils assumed that the underlying wc_to_mb would fill the buffer nearly full and return the size of data it wrote. In fact, this was untrue in the case where wc_to_mb called WideCharToMultiByte: that returns straight-up failure, setting the Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially fill the output buffer, but doesn't tell you how much it wrote! What's wrong with the new API: it's a bit awkward to write a sequence of wchar_t in native byte order to a byte-oriented BinarySink, so people using put_mb_to_wc directly have to do some annoying pointer casting. But I think that's less horrible than the previous APIs. Another change: in the new API for wc_to_mb, defchr can be "", but not NULL.
2024-09-24 07:18:48 +00:00
buffer_sink bs[1];
Debian bug #517535: we were unconditionally interpreting the '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]
2009-02-28 16:52:42 +00:00
Rework Unicode conversion APIs to use a BinarySink. The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs. This commit introduces a fresh pair of functions to replace them, which generate output by writing to a BinarySink. So it's now up to the caller to decide whether it wants the output written to a fixed-size buffer with overflow checking (via buffer_sink), or dynamically allocated, or even written directly to some other output channel. Nothing uses the new functions yet. I plan to migrate things over in upcoming commits. What was wrong with the old APIs: they had that awkward undocumented Windows-specific 'flags' parameter that I described in the previous commit and took out of the dup_X_to_Y wrappers. But much worse, the semantics for buffer overflow were not just undocumented but actually inconsistent. dup_wc_to_mb() in utils assumed that the underlying wc_to_mb would fill the buffer nearly full and return the size of data it wrote. In fact, this was untrue in the case where wc_to_mb called WideCharToMultiByte: that returns straight-up failure, setting the Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially fill the output buffer, but doesn't tell you how much it wrote! What's wrong with the new API: it's a bit awkward to write a sequence of wchar_t in native byte order to a byte-oriented BinarySink, so people using put_mb_to_wc directly have to do some annoying pointer casting. But I think that's less horrible than the previous APIs. Another change: in the new API for wc_to_mb, defchr can be "", but not NULL.
2024-09-24 07:18:48 +00:00
buffer_sink_init(bs, widedata, sizeof(widedata) - sizeof(wchar_t));
put_mb_to_wc(bs, DEFAULT_CODEPAGE,
event_string, strlen(event_string));
wlen = (wchar_t *)bs->out - widedata;
Debian bug #517535: we were unconditionally interpreting the '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]
2009-02-28 16:52:42 +00:00
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
{
char *string_string = dupstr("");
int i;
for (i = 0; i < wlen; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%04x", string_string,
string_string[0] ? " " : "",
(unsigned)widedata[i]);
sfree(old);
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - string translated into Unicode = [%s]\n",
string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(string_string);
}
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
wp = widedata;
ulen = charset_from_unicode(&wp, &wlen, output+1, lenof(output)-2,
CS_UTF8, NULL, NULL, 0);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
{
char *string_string = dupstr("");
int i;
for (i = 0; i < ulen; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i+1] & 0xFF);
sfree(old);
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - string translated into UTF-8 = [%s]\n",
string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(string_string);
}
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
output[1+ulen] = '\0';
}
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif /* !GTK_CHECK_VERSION(2,0,0) */
Debian bug #517535: we were unconditionally interpreting the '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]
2009-02-28 16:52:42 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!output[1] &&
(ucsval = keysym_to_unicode(event->keyval)) >= 0) {
ucsoutput[0] = '\033';
ucsoutput[1] = ucsval;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - keysym_to_unicode gave %04x\n",
(unsigned)ucsoutput[1]);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
use_ucsoutput = true;
end = 2;
} else {
output[lenof(output)-1] = '\0';
end = strlen(output);
}
if (event->state & inst->meta_mod_mask) {
start = 0;
if (end == 1) end = 0;
Work around OS X GTK treating Option as an AltGr key. 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.
2015-09-01 18:10:29 +00:00
#ifdef META_MANUAL_MASK
if (event->state & META_MANUAL_MASK) {
/*
* Key events which have a META_MANUAL_MASK meta bit
* set may have a keyval reflecting that, e.g. on OS X
* the Option key acts as an AltGr-like modifier and
* causes different Unicode characters to be output.
*
* To work around this, we clear the dangerous
* modifier bit and retranslate from the hardware
* keycode as if the key had been pressed without that
* modifier. Then we prefix Esc to *that*.
*/
guint new_keyval;
GdkModifierType consumed;
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
if (gdk_keymap_translate_keyboard_state(
gdk_keymap_get_for_display(gdk_display_get_default()),
event->hardware_keycode,
event->state & ~META_MANUAL_MASK,
0, &new_keyval, NULL, NULL, &consumed)) {
Work around OS X GTK treating Option as an AltGr key. 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.
2015-09-01 18:10:29 +00:00
ucsoutput[0] = '\033';
ucsoutput[1] = gdk_keyval_to_unicode(new_keyval);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
{
char *keyval_name = dup_keyval_name(new_keyval);
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - retranslation for manual Meta: "
"new keyval = %s, Unicode = %04x\n",
keyval_name, (unsigned)ucsoutput[1]);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(keyval_name);
}
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
use_ucsoutput = true;
Work around OS X GTK treating Option as an AltGr key. 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.
2015-09-01 18:10:29 +00:00
end = 2;
}
}
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else
start = 1;
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Control-` is the same as Control-\ (unless gtk has a better idea) */
if (!output[1] && event->keyval == '`' &&
(event->state & GDK_CONTROL_MASK)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-` special case, translating as 1c\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
output[1] = '\x1C';
use_ucsoutput = false;
end = 2;
}
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Handle the Ctrl modifier key ourselves if necessary. 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.
2015-08-31 12:00:42 +00:00
/* Some GTK backends (e.g. Quartz) do not change event->string
* in response to the Control modifier. So we do it ourselves
* here, if it's not already happened.
*
* The translations below are in line with X11 policy as far
* as I know. */
if ((event->state & GDK_CONTROL_MASK) && end == 2) {
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
int orig = use_ucsoutput ? ucsoutput[1] : output[1];
int new = orig;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
if (new >= '3' && new <= '7') {
Handle the Ctrl modifier key ourselves if necessary. 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.
2015-08-31 12:00:42 +00:00
/* ^3,...,^7 map to 0x1B,...,0x1F */
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
new += '\x1B' - '3';
} else if (new == '2' || new == ' ') {
OS X: fix handling of Ctrl-Space. I'd left it out of my simulated Ctrl processing. It should have been treated as \0, the same as ^2 and ^@.
2015-09-01 18:18:26 +00:00
/* ^2 and ^Space are both ^@, i.e. \0 */
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
new = '\0';
} else if (new == '8') {
Handle the Ctrl modifier key ourselves if necessary. 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.
2015-08-31 12:00:42 +00:00
/* ^8 is DEL */
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
new = '\x7F';
} else if (new == '/') {
Handle the Ctrl modifier key ourselves if necessary. 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.
2015-08-31 12:00:42 +00:00
/* ^/ is the same as ^_ */
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
new = '\x1F';
} else if (new >= 0x40 && new < 0x7F) {
Handle the Ctrl modifier key ourselves if necessary. 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.
2015-08-31 12:00:42 +00:00
/* Everything anywhere near the alphabetics just gets
* masked. */
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
new &= 0x1F;
Handle the Ctrl modifier key ourselves if necessary. 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.
2015-08-31 12:00:42 +00:00
}
/* Anything else, e.g. '0', is unchanged. */
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
if (orig == new) {
gtkwin: let ctrl-key fix works without debug mode let 8dfc39bf works when KEY_EVENT_DIAGNOSTICS is not defined
2021-01-11 02:52:34 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - manual Ctrl key handling did nothing\n");
gtkwin: let ctrl-key fix works without debug mode let 8dfc39bf works when KEY_EVENT_DIAGNOSTICS is not defined
2021-01-11 02:52:34 +00:00
#endif
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
} else {
gtkwin: let ctrl-key fix works without debug mode let 8dfc39bf works when KEY_EVENT_DIAGNOSTICS is not defined
2021-01-11 02:52:34 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - manual Ctrl key handling: %02x -> %02x\n",
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
(unsigned)orig, (unsigned)new);
gtkwin: let ctrl-key fix works without debug mode let 8dfc39bf works when KEY_EVENT_DIAGNOSTICS is not defined
2021-01-11 02:52:34 +00:00
#endif
gtk: make Ctrl processing notice if use_ucsoutput is true. Again in the GDK Broadway backend, where we never get a non-Unicode translation of any keystroke: when we come to the code that handles Ctrl+letter (and other symbols), we were basing the Ctrl transform on output[1], that is, the non-Unicode translation we had so far. But we didn't have one. Now we check the use_ucsoutput flag to decide which of output and ucsoutput to start from, and as a result, Ctrl+keys works again on Broadway.
2020-11-24 20:41:25 +00:00
output[1] = new;
use_ucsoutput = false;
}
Handle the Ctrl modifier key ourselves if necessary. 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.
2015-08-31 12:00:42 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Control-Break sends a Break special to the backend */
if (event->keyval == GDK_KEY_Break &&
(event->state & GDK_CONTROL_MASK)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Break special case, sending SS_BRK\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (inst->backend)
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
backend_special(inst->backend, SS_BRK, 0);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return true;
}
Implement the ldisc `special' mechanism in Unix, without which local line editing didn't work at all. [originally from svn r3107]
2003-04-12 09:27:56 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* We handle Return ourselves, because it needs to be flagged as
* special to ldisc. */
if (event->keyval == GDK_KEY_Return) {
Fix handling of Return and keypad Enter. The recent rewriting in both the GTK and Windows keyboard handlers left the keypad 'Enter' key in a bad state, when no override is enabled that causes it to generate an escape sequence. On Windows, a series of fallbacks was causing it to generate \r regardless of configuration, whereas in Telnet mode it should default to generating the special Telnet new-line sequence, and in response to ESC[20h (enabling term->cr_lf_return) it should generate \r\n. On GTK, it wasn't generating anything _at all_, and also, I can't see any evidence that the GTK keyboard handler had ever remembered to implement the cr_lf_return mode. Now Keypad Enter in non-escape-sequence mode should behave just like Return, on both platforms.
2019-04-15 19:43:10 +00:00
end = return_key(inst, output, &special);
use_ucsoutput = false;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
/* Control-2, Control-Space and Control-@ are NUL */
if (!output[1] &&
(event->keyval == ' ' || event->keyval == '2' ||
event->keyval == '@') &&
(event->state & (GDK_SHIFT_MASK |
GDK_CONTROL_MASK)) == GDK_CONTROL_MASK) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-{space,2,@} special case, translating as 00\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
output[1] = '\0';
use_ucsoutput = false;
end = 2;
}
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Control-Shift-Space is 160 (ISO8859 nonbreaking space) */
if (!output[1] && event->keyval == ' ' &&
(event->state & (GDK_SHIFT_MASK | GDK_CONTROL_MASK)) ==
(GDK_SHIFT_MASK | GDK_CONTROL_MASK)) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Ctrl-Shift-space special case, translating as 00a0\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
output[1] = '\240';
output_charset = CS_ISO8859_1;
use_ucsoutput = false;
end = 2;
}
/* We don't let GTK tell us what Backspace is! We know better. */
if (event->keyval == GDK_KEY_BackSpace &&
!(event->state & GDK_SHIFT_MASK)) {
output[1] = conf_get_bool(inst->conf, CONF_bksp_is_delete) ?
'\x7F' : '\x08';
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Backspace, translating as %02x\n",
(unsigned)output[1]);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
use_ucsoutput = false;
end = 2;
special = true;
}
/* For Shift Backspace, do opposite of what is configured. */
if (event->keyval == GDK_KEY_BackSpace &&
(event->state & GDK_SHIFT_MASK)) {
output[1] = conf_get_bool(inst->conf, CONF_bksp_is_delete) ?
'\x08' : '\x7F';
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-Backspace, translating as %02x\n",
(unsigned)output[1]);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
use_ucsoutput = false;
end = 2;
special = true;
}
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Shift-Tab is ESC [ Z */
if (event->keyval == GDK_KEY_ISO_Left_Tab ||
(event->keyval == GDK_KEY_Tab &&
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
(event->state & GDK_SHIFT_MASK))) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Shift-Tab, translating as ESC [ Z\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
end = 1 + sprintf(output+1, "\033[Z");
use_ucsoutput = false;
}
/* And normal Tab is Tab, if the keymap hasn't already told us.
* (Curiously, at least one version of the MacOS 10.5 X server
* doesn't translate Tab for us. */
if (event->keyval == GDK_KEY_Tab && end <= 1) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - Tab, translating as 09\n");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
output[1] = '\t';
end = 2;
}
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (num_keypad_key && force_format_numeric_keypad) {
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
end = 1 + format_numeric_keypad_key(
output+1, inst->term, num_keypad_key,
event->state & GDK_SHIFT_MASK,
event->state & GDK_CONTROL_MASK);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - numeric keypad key");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
use_ucsoutput = false;
goto done;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Support NetHack keypad mode. :-) [originally from svn r2046]
2002-10-14 10:06:07 +00:00
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
switch (event->keyval) {
int fkey_number;
Fix Alt handling in the new shifted-arrow-key support. As well as affecting the bitmap field in the escape sequence, it was _also_ having its otherwise standard effect of prefixing Esc to the whole sequence. It shouldn't do both.
2021-10-23 09:52:11 +00:00
bool consumed_meta_key;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
case GDK_KEY_F1: fkey_number = 1; goto numbered_function_key;
case GDK_KEY_F2: fkey_number = 2; goto numbered_function_key;
case GDK_KEY_F3: fkey_number = 3; goto numbered_function_key;
case GDK_KEY_F4: fkey_number = 4; goto numbered_function_key;
case GDK_KEY_F5: fkey_number = 5; goto numbered_function_key;
case GDK_KEY_F6: fkey_number = 6; goto numbered_function_key;
case GDK_KEY_F7: fkey_number = 7; goto numbered_function_key;
case GDK_KEY_F8: fkey_number = 8; goto numbered_function_key;
case GDK_KEY_F9: fkey_number = 9; goto numbered_function_key;
case GDK_KEY_F10: fkey_number = 10; goto numbered_function_key;
case GDK_KEY_F11: fkey_number = 11; goto numbered_function_key;
case GDK_KEY_F12: fkey_number = 12; goto numbered_function_key;
case GDK_KEY_F13: fkey_number = 13; goto numbered_function_key;
case GDK_KEY_F14: fkey_number = 14; goto numbered_function_key;
case GDK_KEY_F15: fkey_number = 15; goto numbered_function_key;
case GDK_KEY_F16: fkey_number = 16; goto numbered_function_key;
case GDK_KEY_F17: fkey_number = 17; goto numbered_function_key;
case GDK_KEY_F18: fkey_number = 18; goto numbered_function_key;
case GDK_KEY_F19: fkey_number = 19; goto numbered_function_key;
case GDK_KEY_F20: fkey_number = 20; goto numbered_function_key;
numbered_function_key:
New function-key mode similar to modern xterm. This is the same as the previous FUNKY_XTERM mode if you don't press any modifier keys, but now Shift or Ctrl or Alt with function keys adds an extra bitmap parameter. The bitmaps are the same as the ones used by the new SHARROW_BITMAP arrow key mode.
2021-10-23 10:04:53 +00:00
consumed_meta_key = false;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
end = 1 + format_function_key(output+1, inst->term, fkey_number,
event->state & GDK_SHIFT_MASK,
New function-key mode similar to modern xterm. This is the same as the previous FUNKY_XTERM mode if you don't press any modifier keys, but now Shift or Ctrl or Alt with function keys adds an extra bitmap parameter. The bitmaps are the same as the ones used by the new SHARROW_BITMAP arrow key mode.
2021-10-23 10:04:53 +00:00
event->state & GDK_CONTROL_MASK,
event->state & inst->meta_mod_mask,
&consumed_meta_key);
if (consumed_meta_key)
start = 1; /* supersedes the usual prefixing of Esc */
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - function key F%d", fkey_number);
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
#endif
use_ucsoutput = false;
goto done;
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
SmallKeypadKey sk_key;
case GDK_KEY_Home: case GDK_KEY_KP_Home:
sk_key = SKK_HOME; goto small_keypad_key;
case GDK_KEY_Insert: case GDK_KEY_KP_Insert:
sk_key = SKK_INSERT; goto small_keypad_key;
case GDK_KEY_Delete: case GDK_KEY_KP_Delete:
sk_key = SKK_DELETE; goto small_keypad_key;
case GDK_KEY_End: case GDK_KEY_KP_End:
sk_key = SKK_END; goto small_keypad_key;
case GDK_KEY_Page_Up: case GDK_KEY_KP_Page_Up:
sk_key = SKK_PGUP; goto small_keypad_key;
case GDK_KEY_Page_Down: case GDK_KEY_KP_Page_Down:
sk_key = SKK_PGDN; goto small_keypad_key;
small_keypad_key:
/* These keys don't generate terminal input with Ctrl */
if (event->state & GDK_CONTROL_MASK)
break;
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Unix PuTTY/pterm: fix UB with small keypad. We were relying on uninitialised data. Found by UBSAN. (Introduced in commit c88b6d1853, I think.)
2024-12-04 17:21:30 +00:00
consumed_meta_key = false;
Formatting: miscellaneous. This patch fixes a few other whitespace and formatting issues which were pointed out by the bulk-reindent or which I spotted in passing, some involving manual editing to break lines more nicely. I think the weirdest hunk in here is the one in windows/window.c TranslateKey() where _half_ of an assignment statement inside an 'if' was on the same line as the trailing paren of the if condition. No idea at all how that one managed to happen!
2022-08-03 19:48:46 +00:00
end = 1 + format_small_keypad_key(
output+1, inst->term, sk_key, event->state & GDK_SHIFT_MASK,
event->state & GDK_CONTROL_MASK,
event->state & inst->meta_mod_mask, &consumed_meta_key);
Send xterm 216+ modifiers in small-keypad key escape sequences. In the 'xterm 216+' function key mode, a function key pressed with a combination of Shift, Ctrl and Alt has its usual sequence like ESC[n~ (for some integer n) turned into ESC[n;m~ where m-1 is a 3-bit bitmap of currently pressed modifier keys. This mode now also applies to the keys on the small keypad above the arrow keys (Ins, Home, PgUp etc). If xterm 216+ mode is selected, those keys are modified in the same way as the function keys. As with the function keys, this doesn't guarantee that PuTTY will _receive_ any particular shifted key of this kind, and not repurpose it. Just as Alt+F4 still closes the window (at least on Windows) rather than sending a modified F4 sequence, Shift+Ins will still perform a paste action rather than sending a modified Ins sequence, Shift-PgUp will still scroll the scrollback, etc. But the keys not already used by PuTTY for other purposes should now have their modern-xterm behaviour in modern-xterm mode. Thanks to H.Merijn Brand for developing and testing a version of this patch.
2022-07-24 12:54:32 +00:00
if (consumed_meta_key)
start = 1; /* supersedes the usual prefixing of Esc */
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - small keypad key");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
use_ucsoutput = false;
goto done;
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int xkey;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
case GDK_KEY_Up: case GDK_KEY_KP_Up:
xkey = 'A'; goto arrow_key;
case GDK_KEY_Down: case GDK_KEY_KP_Down:
xkey = 'B'; goto arrow_key;
case GDK_KEY_Right: case GDK_KEY_KP_Right:
xkey = 'C'; goto arrow_key;
case GDK_KEY_Left: case GDK_KEY_KP_Left:
xkey = 'D'; goto arrow_key;
case GDK_KEY_Begin: case GDK_KEY_KP_Begin:
xkey = 'G'; goto arrow_key;
arrow_key:
Fix Alt handling in the new shifted-arrow-key support. As well as affecting the bitmap field in the escape sequence, it was _also_ having its otherwise standard effect of prefixing Esc to the whole sequence. It shouldn't do both.
2021-10-23 09:52:11 +00:00
consumed_meta_key = false;
Formatting: miscellaneous. This patch fixes a few other whitespace and formatting issues which were pointed out by the bulk-reindent or which I spotted in passing, some involving manual editing to break lines more nicely. I think the weirdest hunk in here is the one in windows/window.c TranslateKey() where _half_ of an assignment statement inside an 'if' was on the same line as the trailing paren of the if condition. No idea at all how that one managed to happen!
2022-08-03 19:48:46 +00:00
end = 1 + format_arrow_key(
output+1, inst->term, xkey, event->state & GDK_SHIFT_MASK,
event->state & GDK_CONTROL_MASK,
event->state & inst->meta_mod_mask, &consumed_meta_key);
Fix Alt handling in the new shifted-arrow-key support. As well as affecting the bitmap field in the escape sequence, it was _also_ having its otherwise standard effect of prefixing Esc to the whole sequence. It shouldn't do both.
2021-10-23 09:52:11 +00:00
if (consumed_meta_key)
start = 1; /* supersedes the usual prefixing of Esc */
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - arrow key");
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
#endif
use_ucsoutput = false;
goto done;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (num_keypad_key) {
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
end = 1 + format_numeric_keypad_key(
output+1, inst->term, num_keypad_key,
event->state & GDK_SHIFT_MASK,
event->state & GDK_CONTROL_MASK);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - numeric keypad key");
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#endif
Fix handling of Return and keypad Enter. The recent rewriting in both the GTK and Windows keyboard handlers left the keypad 'Enter' key in a bad state, when no override is enabled that causes it to generate an escape sequence. On Windows, a series of fallbacks was causing it to generate \r regardless of configuration, whereas in Telnet mode it should default to generating the special Telnet new-line sequence, and in response to ESC[20h (enabling term->cr_lf_return) it should generate \r\n. On GTK, it wasn't generating anything _at all_, and also, I can't see any evidence that the GTK keyboard handler had ever remembered to implement the cr_lf_return mode. Now Keypad Enter in non-escape-sequence mode should behave just like Return, on both platforms.
2019-04-15 19:43:10 +00:00
if (end == 1 && num_keypad_key == '\r') {
/* Keypad Enter, lacking any other translation,
* becomes the same special Return code as normal
* Return. */
end = return_key(inst, output, &special);
use_ucsoutput = false;
}
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
use_ucsoutput = false;
goto done;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
goto done;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
}
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Formatting: realign labels and case/default statements. My aim has always been to have those back-dented by 2 spaces (half an indent level) compared to the statements around them, so that in particular switch statements have distinct alignment for the statement, the cases and the interior code without consuming two whole indent levels. This patch sweeps up all the violations of that principle found by my bulk-reindentation exercise.
2022-08-03 19:48:46 +00:00
done:
Half-decent keyboard handling for pterm. Not very well done - it 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]
2002-10-10 12:14:05 +00:00
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 17:18:24 +00:00
if (end-start > 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (special) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i] & 0xFF);
sfree(old);
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - final output, special, generic encoding = [%s]\n",
Fix printf warnings at -DDEBUG. I must have not recompiled with debug printouts enabled since updating the internal printf functions to have the gcc printf attribute, or these warnings would surely have come up before.
2020-11-24 20:38:36 +00:00
string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(string_string);
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* For special control characters, the character set
* should never matter.
*/
output[end] = '\0'; /* NUL-terminate */
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
generated_something = true;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinput(inst->term, -1, output+start, -2);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (!inst->direct_to_font) {
if (!use_ucsoutput) {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i] & 0xFF);
sfree(old);
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - final output in %s = [%s]\n",
charset_to_localenc(output_charset), string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(string_string);
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
generated_something = true;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinput(inst->term, output_charset,
output+start, end-start);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%04x", string_string,
string_string[0] ? " " : "",
(unsigned)ucsoutput[i]);
sfree(old);
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - final output in Unicode = [%s]\n",
string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(string_string);
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* We generated our own Unicode key data from the
* keysym, so use that instead.
*/
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
generated_something = true;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinputw(inst->term, ucsoutput+start, end-start);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
} else {
/*
* In direct-to-font mode, we just send the string
* exactly as we received it.
*/
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i] & 0xFF);
sfree(old);
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - final output in direct-to-font encoding = [%s]\n",
string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(string_string);
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
generated_something = true;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinput(inst->term, -1, output+start, end-start);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
show_mouseptr(inst, false);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Remove frontend_keypress(). This was used by ldisc to communicate back to the front end that a key had been pressed (or rather, that a keypress had caused a nonzero amount of session input data). Its only nontrivial implementation was in gtkwin.c, which used that notification to implement the Unix GUI's "close window on keypress, if the session was already over" policy. (Which in turn is Unix-specific, because the rationale is that sometimes X servers don't have a functioning window manager, so it's useful to have a way of telling any application to close without using WM-provided facilities like a close button.) But gtkwin.c doesn't need to be told by the ldisc that a keypress happened - it's the one _sending_ those keypresses to ldisc in the first place! So I've thrown away the three stub implementations of frontend_keypress, removed the call to it in ldisc.c, and replaced it with calls in gtkwin.c at all the points during keypress handling that call ldisc_send. A visible effect is that pterm's close-on-keypress behaviour will now only trigger on an actual (input-generating) _keypress_, and not on other input generation such as a paste action. I think that's an improvement.
2018-10-11 17:14:05 +00:00
if (generated_something)
key_pressed(inst);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
}
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
void input_method_commit_event(GtkIMContext *imc, gchar *str, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = 0; str[i]; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)str[i] & 0xFF);
sfree(old);
}
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug(" - IM commit event in UTF-8 = [%s]\n", string_string);
Clean up GTK keyboard event diagnostics. 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.
2015-09-06 08:13:48 +00:00
sfree(string_string);
#endif
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinput(inst->term, CS_UTF8, str, strlen(str));
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
show_mouseptr(inst, false);
Remove frontend_keypress(). This was used by ldisc to communicate back to the front end that a key had been pressed (or rather, that a keypress had caused a nonzero amount of session input data). Its only nontrivial implementation was in gtkwin.c, which used that notification to implement the Unix GUI's "close window on keypress, if the session was already over" policy. (Which in turn is Unix-specific, because the rationale is that sometimes X servers don't have a functioning window manager, so it's useful to have a way of telling any application to close without using WM-provided facilities like a close button.) But gtkwin.c doesn't need to be told by the ldisc that a keypress happened - it's the one _sending_ those keypresses to ldisc in the first place! So I've thrown away the three stub implementations of frontend_keypress, removed the call to it in ldisc.c, and replaced it with calls in gtkwin.c at all the points during keypress handling that call ldisc_send. A visible effect is that pterm's close-on-keypress behaviour will now only trigger on an actual (input-generating) _keypress_, and not on other input generation such as a paste action. I think that's an improvement.
2018-10-11 17:14:05 +00:00
key_pressed(inst);
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
}
#endif
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
#define SCROLL_INCREMENT_LINES 5
#if GTK_CHECK_VERSION(3,4,0)
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
gboolean scroll_internal(GtkFrontend *inst, gdouble xdelta, gdouble ydelta,
guint state, gdouble ex, gdouble ey)
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int x, y;
bool shift, ctrl, alt, raw_mouse_mode;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
show_mouseptr(inst, true);
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
shift = state & GDK_SHIFT_MASK;
ctrl = state & GDK_CONTROL_MASK;
alt = state & inst->meta_mod_mask;
x = (ex - inst->window_border) / inst->font_width;
y = (ey - inst->window_border) / inst->font_height;
Make send_raw_mouse a field of GtkFrontend. I came across this unexplained static variable in my boolification trawl. It seems clearly unintentional that it has only one instance instead of one per terminal window - the code in question closely resembles the Windows front end, and I think this must just be a variable that I never swept up into 'inst' in the very early days when I was making gtkwin.c out of a cloned-and-hacked window.c in the first place. These days it's even a bug, now that the OS X port actually does run multiple terminal windows in the same process: if one goes into mouse reporting mode, I'm pretty sure this would have done confusing things to the effects of mouse actions in the other.
2018-11-03 08:17:44 +00:00
raw_mouse_mode = (inst->send_raw_mouse &&
!(shift && conf_get_bool(inst->conf,
CONF_mouse_override)));
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
inst->cumulative_vscroll += ydelta * SCROLL_INCREMENT_LINES;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
if (!raw_mouse_mode) {
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
int scroll_lines = (int)inst->cumulative_vscroll; /* rounds toward 0 */
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
if (scroll_lines) {
term_scroll(inst->term, 0, scroll_lines);
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
inst->cumulative_vscroll -= scroll_lines;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
} else {
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
int scroll_events = (int)(inst->cumulative_vscroll /
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
SCROLL_INCREMENT_LINES);
if (scroll_events) {
int button;
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
inst->cumulative_vscroll -= scroll_events * SCROLL_INCREMENT_LINES;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
if (scroll_events > 0) {
button = MBT_WHEEL_DOWN;
} else {
button = MBT_WHEEL_UP;
scroll_events = -scroll_events;
}
while (scroll_events-- > 0) {
term_mouse(inst->term, button, translate_button(button),
MA_CLICK, x, y, shift, ctrl, alt);
}
}
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
/*
* Now do the same for horizontal scrolling. But because we
* _only_ use that for passing through to mouse reporting, we
* don't even collect the scroll deltas while not in
* raw_mouse_mode. (Otherwise there would likely be a huge
* unexpected lurch when raw_mouse_mode was enabled!)
*/
inst->cumulative_hscroll += xdelta * SCROLL_INCREMENT_LINES;
scroll_events = (int)(inst->cumulative_hscroll /
SCROLL_INCREMENT_LINES);
if (scroll_events) {
int button;
inst->cumulative_hscroll -= scroll_events * SCROLL_INCREMENT_LINES;
if (scroll_events > 0) {
button = MBT_WHEEL_RIGHT;
} else {
button = MBT_WHEEL_LEFT;
scroll_events = -scroll_events;
}
while (scroll_events-- > 0) {
term_mouse(inst->term, button, translate_button(button),
MA_CLICK, x, y, shift, ctrl, alt);
}
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
}
}
#endif
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static gboolean button_internal(GtkFrontend *inst, GdkEventButton *event)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool shift, ctrl, alt, raw_mouse_mode;
int x, y, button, act;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Richard Boulton's patch for improved correctness in selection handling (generally, selection request timestamps should be set to the timestamp on the event that caused them). [originally from svn r3408]
2003-08-21 18:03:06 +00:00
/* Remember the timestamp. */
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
inst->input_event_time = event->time;
Richard Boulton's patch for improved correctness in selection handling (generally, selection request timestamps should be set to the timestamp on the event that caused them). [originally from svn r3408]
2003-08-21 18:03:06 +00:00
Label random-noise sources with an enum of ids. The upcoming PRNG revamp will want to tell noise sources apart, so that it can treat them all fairly. So I've added an extra parameter to noise_ultralight and random_add_noise, which takes values in an enumeration covering all the vague classes of entropy source I'm collecting. In this commit, though, it's simply ignored.
2019-01-22 18:25:54 +00:00
noise_ultralight(NOISE_SOURCE_MOUSEBUTTON, event->button);
Add more random-number noise collection calls. Mostly on the Unix side: there are lots of places the Windows code was collecting noise that the corresponding Unix/GTK code wasn't bothering to, such as mouse movements, keystrokes and various network events. Also, both platforms had forgotten to collect noise when reading data from a pipe to a local proxy process, even though in that configuration that's morally equivalent to the network packet timings that we'd normally be collecting from.
2019-01-22 21:01:26 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
show_mouseptr(inst, true);
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 09:58:27 +00:00
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
shift = event->state & GDK_SHIFT_MASK;
ctrl = event->state & GDK_CONTROL_MASK;
alt = event->state & inst->meta_mod_mask;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
Make send_raw_mouse a field of GtkFrontend. I came across this unexplained static variable in my boolification trawl. It seems clearly unintentional that it has only one instance instead of one per terminal window - the code in question closely resembles the Windows front end, and I think this must just be a variable that I never swept up into 'inst' in the very early days when I was making gtkwin.c out of a cloned-and-hacked window.c in the first place. These days it's even a bug, now that the OS X port actually does run multiple terminal windows in the same process: if one goes into mouse reporting mode, I'm pretty sure this would have done confusing things to the effects of mouse actions in the other.
2018-11-03 08:17:44 +00:00
raw_mouse_mode = (inst->send_raw_mouse &&
!(shift && conf_get_bool(inst->conf,
CONF_mouse_override)));
Enable xterm mouse reporting of wheel actions in GTK. I had somehow missed this completely out of the GTK mouse-button handling and never noticed until now! Of course, like any other mouse action, if you want it to be handled locally rather than passed through then you can hold down Shift. [originally from svn r10139]
2014-02-16 16:40:46 +00:00
if (!raw_mouse_mode) {
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
if (event->button == 4 && event->type == GDK_BUTTON_PRESS) {
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
term_scroll(inst->term, 0, -SCROLL_INCREMENT_LINES);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Enable xterm mouse reporting of wheel actions in GTK. I had somehow missed this completely out of the GTK mouse-button handling and never noticed until now! Of course, like any other mouse action, if you want it to be handled locally rather than passed through then you can hold down Shift. [originally from svn r10139]
2014-02-16 16:40:46 +00:00
}
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
if (event->button == 5 && event->type == GDK_BUTTON_PRESS) {
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
term_scroll(inst->term, 0, +SCROLL_INCREMENT_LINES);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Enable xterm mouse reporting of wheel actions in GTK. I had somehow missed this completely out of the GTK mouse-button handling and never noticed until now! Of course, like any other mouse action, if you want it to be handled locally rather than passed through then you can hold down Shift. [originally from svn r10139]
2014-02-16 16:40:46 +00:00
}
}
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
if (event->button == 3 && ctrl) {
Cancel drag-select when the context menu pops up. I got a pterm into a stuck state this morning by an accidental mouse action. I'd intended to press Ctrl + right-click to pop up the context menu, but I accidentally pressed down the left button first, starting a selection drag, and then while the left button was still held down, pressed down the right button as well, triggering the menu. The effect was that the context menu appeared while term->selstate was set to DRAGGING, in which state terminal output is suppressed, and which is only unset by a mouse-button release event. But then that release event went to the popup menu, and the terminal window never got it. So the terminal stayed stuck forever - or rather, until I guessed the cause and did another selection drag to reset it. This happened to me on GTK, but once I knew how I'd done it, I found I could reproduce the same misbehaviour on Windows by the same method. Added a simplistic fix, on both platforms, that cancels a selection drag if the popup menu is summoned part way through it.
2022-03-29 17:05:11 +00:00
/* Just in case this happened in mid-select */
term_cancel_selection_drag(inst->term);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
#if GTK_CHECK_VERSION(3,22,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_menu_popup_at_pointer(GTK_MENU(inst->menu), (GdkEvent *)event);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_menu_popup(GTK_MENU(inst->menu), NULL, NULL, NULL, NULL,
event->button, event->time);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return true;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
if (event->button == 1)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_LEFT;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
else if (event->button == 2)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_MIDDLE;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
else if (event->button == 3)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_RIGHT;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
else if (event->button == 4)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_WHEEL_UP;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
else if (event->button == 5)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_WHEEL_DOWN;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false; /* don't even know what button! */
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
switch (event->type) {
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
case GDK_BUTTON_PRESS: act = MA_CLICK; break;
case GDK_BUTTON_RELEASE: act = MA_RELEASE; break;
case GDK_2BUTTON_PRESS: act = MA_2CLK; break;
case GDK_3BUTTON_PRESS: act = MA_3CLK; break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
default: return false; /* don't know this event type */
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
Enable xterm mouse reporting of wheel actions in GTK. I had somehow missed this completely out of the GTK mouse-button handling and never noticed until now! Of course, like any other mouse action, if you want it to be handled locally rather than passed through then you can hold down Shift. [originally from svn r10139]
2014-02-16 16:40:46 +00:00
if (raw_mouse_mode && act != MA_CLICK && act != MA_RELEASE)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return true; /* we ignore these in raw mouse mode */
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
x = (event->x - inst->window_border) / inst->font_width;
y = (event->y - inst->window_border) / inst->font_height;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Change the term_mouse interface a little so that it gets passed both the raw and the cooked mouse button, with the mapping being done in advance by the front-end. This is useful because it allows the front-end to use information other than the raw button (e.g. the modifier state) to decide which cooked button to generate. . Front ends other than the Mac one are untested, but they just call translate_button() themselves and pass the result to term_mouse(). [originally from svn r2721]
2003-01-25 16:16:45 +00:00
term_mouse(inst->term, button, translate_button(button), act,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x, y, shift, ctrl, alt);
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
gboolean button_event(GtkWidget *widget, GdkEventButton *event, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
return button_internal(inst, event);
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
}
#if GTK_CHECK_VERSION(2,0,0)
/*
* In GTK 2, mouse wheel events have become a new type of event.
* This handler translates them back into button-4 and button-5
* presses so that I don't have to change my old code too much :-)
*/
gboolean scroll_event(GtkWidget *widget, GdkEventScroll *event, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
gtk: fill in missing case in scroll_event(). If gdk_event_get_scroll_deltas() return failure for a given GdkEventScroll, it doesn't follow that that event has no usable scrolling action in it at all. The fallback is to call gdk_event_get_scroll_direction() instead, which is less precise but still gives _something_ you can use. So in that situation, instead of just returning false, we can fall through to the handling we use for pre-GTK3 scroll events (which are always imprecise). In particular, I've noticed recently that if you run GTK 3 PuTTY in the virtual X display created by vnc4server, and connect to it using xtightvncviewer, then scroll-wheel actions passed through from the VNC client will cause scroll_event() to receive low-res GdkEventScroll structures of exactly this kind. So scroll-wheel activity on the terminal window wasn't causing a scroll in that environment, and with this patch, it does.
2020-04-03 16:56:30 +00:00
GdkScrollDirection dir;
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
#if GTK_CHECK_VERSION(3,4,0)
gdouble dx, dy;
if (gdk_event_get_scroll_deltas((GdkEvent *)event, &dx, &dy)) {
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
return scroll_internal(inst, dx, dy, event->state, event->x, event->y);
gtk: fill in missing case in scroll_event(). If gdk_event_get_scroll_deltas() return failure for a given GdkEventScroll, it doesn't follow that that event has no usable scrolling action in it at all. The fallback is to call gdk_event_get_scroll_direction() instead, which is less precise but still gives _something_ you can use. So in that situation, instead of just returning false, we can fall through to the handling we use for pre-GTK3 scroll events (which are always imprecise). In particular, I've noticed recently that if you run GTK 3 PuTTY in the virtual X display created by vnc4server, and connect to it using xtightvncviewer, then scroll-wheel actions passed through from the VNC client will cause scroll_event() to receive low-res GdkEventScroll structures of exactly this kind. So scroll-wheel activity on the terminal window wasn't causing a scroll in that environment, and with this patch, it does.
2020-04-03 16:56:30 +00:00
} else if (!gdk_event_get_scroll_direction((GdkEvent *)event, &dir)) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
gtk: fill in missing case in scroll_event(). If gdk_event_get_scroll_deltas() return failure for a given GdkEventScroll, it doesn't follow that that event has no usable scrolling action in it at all. The fallback is to call gdk_event_get_scroll_direction() instead, which is less precise but still gives _something_ you can use. So in that situation, instead of just returning false, we can fall through to the handling we use for pre-GTK3 scroll events (which are always imprecise). In particular, I've noticed recently that if you run GTK 3 PuTTY in the virtual X display created by vnc4server, and connect to it using xtightvncviewer, then scroll-wheel actions passed through from the VNC client will cause scroll_event() to receive low-res GdkEventScroll structures of exactly this kind. So scroll-wheel activity on the terminal window wasn't causing a scroll in that environment, and with this patch, it does.
2020-04-03 16:56:30 +00:00
}
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
#else
gtk: fill in missing case in scroll_event(). If gdk_event_get_scroll_deltas() return failure for a given GdkEventScroll, it doesn't follow that that event has no usable scrolling action in it at all. The fallback is to call gdk_event_get_scroll_direction() instead, which is less precise but still gives _something_ you can use. So in that situation, instead of just returning false, we can fall through to the handling we use for pre-GTK3 scroll events (which are always imprecise). In particular, I've noticed recently that if you run GTK 3 PuTTY in the virtual X display created by vnc4server, and connect to it using xtightvncviewer, then scroll-wheel actions passed through from the VNC client will cause scroll_event() to receive low-res GdkEventScroll structures of exactly this kind. So scroll-wheel activity on the terminal window wasn't causing a scroll in that environment, and with this patch, it does.
2020-04-03 16:56:30 +00:00
dir = event->direction;
#endif
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
guint button;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
GdkEventButton *event_button;
gboolean ret;
gtk: fill in missing case in scroll_event(). If gdk_event_get_scroll_deltas() return failure for a given GdkEventScroll, it doesn't follow that that event has no usable scrolling action in it at all. The fallback is to call gdk_event_get_scroll_direction() instead, which is less precise but still gives _something_ you can use. So in that situation, instead of just returning false, we can fall through to the handling we use for pre-GTK3 scroll events (which are always imprecise). In particular, I've noticed recently that if you run GTK 3 PuTTY in the virtual X display created by vnc4server, and connect to it using xtightvncviewer, then scroll-wheel actions passed through from the VNC client will cause scroll_event() to receive low-res GdkEventScroll structures of exactly this kind. So scroll-wheel activity on the terminal window wasn't causing a scroll in that environment, and with this patch, it does.
2020-04-03 16:56:30 +00:00
if (dir == GDK_SCROLL_UP)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = 4;
gtk: fill in missing case in scroll_event(). If gdk_event_get_scroll_deltas() return failure for a given GdkEventScroll, it doesn't follow that that event has no usable scrolling action in it at all. The fallback is to call gdk_event_get_scroll_direction() instead, which is less precise but still gives _something_ you can use. So in that situation, instead of just returning false, we can fall through to the handling we use for pre-GTK3 scroll events (which are always imprecise). In particular, I've noticed recently that if you run GTK 3 PuTTY in the virtual X display created by vnc4server, and connect to it using xtightvncviewer, then scroll-wheel actions passed through from the VNC client will cause scroll_event() to receive low-res GdkEventScroll structures of exactly this kind. So scroll-wheel activity on the terminal window wasn't causing a scroll in that environment, and with this patch, it does.
2020-04-03 16:56:30 +00:00
else if (dir == GDK_SCROLL_DOWN)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = 5;
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
event_button = (GdkEventButton *)gdk_event_new(GDK_BUTTON_PRESS);
Stop Gtk2 builds exploding on scroll wheel events. More fallout from 64221972c.
2017-05-20 11:44:56 +00:00
event_button->window = g_object_ref(event->window);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
event_button->send_event = event->send_event;
event_button->time = event->time;
event_button->x = event->x;
event_button->y = event->y;
event_button->axes = NULL;
event_button->state = event->state;
event_button->button = button;
Stop Gtk2 builds exploding on scroll wheel events. More fallout from 64221972c.
2017-05-20 11:44:56 +00:00
event_button->device = g_object_ref(event->device);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
event_button->x_root = event->x_root;
event_button->y_root = event->y_root;
ret = button_internal(inst, event_button);
Add a cast to fix a warning. This fixes compilation with Gtk 2 with -Werror. Problem introduced by 64221972c.
2017-04-30 10:39:07 +00:00
gdk_event_free((GdkEvent *)event_button);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-05 21:41:21 +00:00
return ret;
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
}
#endif
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
gint motion_event(GtkWidget *widget, GdkEventMotion *event, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool shift, ctrl, alt;
Support xterm any-event mouse tracking From https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Any-event-tracking: Any-event mode is the same as button-event mode, except that all motion events are reported, even if no mouse button is down. It is enabled by specifying 1003 to DECSET. Normally the front ends only report mouse events when buttons are pressed, so we introduce a MA_MOVE event with MBT_NOTHING set to indicate such a mouse movement.
2019-12-20 13:56:58 +00:00
Mouse_Action action = MA_DRAG;
Mouse_Button button = MBT_NOTHING;
int x, y;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Richard Boulton's patch for improved correctness in selection handling (generally, selection request timestamps should be set to the timestamp on the event that caused them). [originally from svn r3408]
2003-08-21 18:03:06 +00:00
/* Remember the timestamp. */
inst->input_event_time = event->time;
Label random-noise sources with an enum of ids. The upcoming PRNG revamp will want to tell noise sources apart, so that it can treat them all fairly. So I've added an extra parameter to noise_ultralight and random_add_noise, which takes values in an enumeration covering all the vague classes of entropy source I'm collecting. In this commit, though, it's simply ignored.
2019-01-22 18:25:54 +00:00
noise_ultralight(NOISE_SOURCE_MOUSEPOS,
((uint32_t)event->x << 16) | (uint32_t)event->y);
Add more random-number noise collection calls. Mostly on the Unix side: there are lots of places the Windows code was collecting noise that the corresponding Unix/GTK code wasn't bothering to, such as mouse movements, keystrokes and various network events. Also, both platforms had forgotten to collect noise when reading data from a pipe to a local proxy process, even though in that configuration that's morally equivalent to the network packet timings that we'd normally be collecting from.
2019-01-22 21:01:26 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
show_mouseptr(inst, true);
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 09:58:27 +00:00
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
shift = event->state & GDK_SHIFT_MASK;
ctrl = event->state & GDK_CONTROL_MASK;
On OS X, be able to configure either Option or Command as Meta. 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.
2015-09-01 18:00:25 +00:00
alt = event->state & inst->meta_mod_mask;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
if (event->state & GDK_BUTTON1_MASK)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_LEFT;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
else if (event->state & GDK_BUTTON2_MASK)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_MIDDLE;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
else if (event->state & GDK_BUTTON3_MASK)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
button = MBT_RIGHT;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
else
Support xterm any-event mouse tracking From https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Any-event-tracking: Any-event mode is the same as button-event mode, except that all motion events are reported, even if no mouse button is down. It is enabled by specifying 1003 to DECSET. Normally the front ends only report mouse events when buttons are pressed, so we introduce a MA_MOVE event with MBT_NOTHING set to indicate such a mouse movement.
2019-12-20 13:56:58 +00:00
action = MA_MOVE;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
x = (event->x - inst->window_border) / inst->font_width;
y = (event->y - inst->window_border) / inst->font_height;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Support xterm any-event mouse tracking From https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Any-event-tracking: Any-event mode is the same as button-event mode, except that all motion events are reported, even if no mouse button is down. It is enabled by specifying 1003 to DECSET. Normally the front ends only report mouse events when buttons are pressed, so we introduce a MA_MOVE event with MBT_NOTHING set to indicate such a mouse movement.
2019-12-20 13:56:58 +00:00
term_mouse(inst->term, button, translate_button(button), action,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x, y, shift, ctrl, alt);
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void key_pressed(GtkFrontend *inst)
Implement handling of all Close On Exit modes. Default is to close 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]
2002-10-23 14:21:12 +00:00
{
/*
* If our child process has exited but not closed, terminate on
* any keypress.
Remove frontend_keypress(). This was used by ldisc to communicate back to the front end that a key had been pressed (or rather, that a keypress had caused a nonzero amount of session input data). Its only nontrivial implementation was in gtkwin.c, which used that notification to implement the Unix GUI's "close window on keypress, if the session was already over" policy. (Which in turn is Unix-specific, because the rationale is that sometimes X servers don't have a functioning window manager, so it's useful to have a way of telling any application to close without using WM-provided facilities like a close button.) But gtkwin.c doesn't need to be told by the ldisc that a keypress happened - it's the one _sending_ those keypresses to ldisc in the first place! So I've thrown away the three stub implementations of frontend_keypress, removed the call to it in ldisc.c, and replaced it with calls in gtkwin.c at all the points during keypress handling that call ldisc_send. A visible effect is that pterm's close-on-keypress behaviour will now only trigger on an actual (input-generating) _keypress_, and not on other input generation such as a paste action. I think that's an improvement.
2018-10-11 17:14:05 +00:00
*
* This is a UI feature specific to GTK PuTTY, because GTK PuTTY
* will (at least sometimes) be running under X, and under X the
* window manager is sometimes absent (very occasionally on
* purpose, more usually temporarily because it's crashed). So
* it's useful to have a way to close an application window
* without depending on protocols like WM_DELETE_WINDOW that are
* typically generated by the WM (e.g. in response to a close
* button in the window frame).
Implement handling of all Close On Exit modes. Default is to close 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]
2002-10-23 14:21:12 +00:00
*/
if (inst->exited)
Remove one last stray process exit(). This one's in frontend_keypress(), which is supposed to close the window on the first keypress after the session inside it terminates (that is, if your close-on-exit settings haven't made it close already at that point). It looks to me as if that behaviour doesn't currently _work_, and hasn't worked for quite a while (certainly it was broken as of 0.70, well before I started on this weekend's refactoring), because when the session terminates we delete inst->ldisc and that's what would otherwise be calling frontend_keypress. I should probably decide what to do about that at some point. But for the moment, I'm satisfied to simply not break this functionality any worse by making it not a process-global exit :-)
2017-11-27 20:18:23 +00:00
gtk_widget_destroy(inst->window);
Implement handling of all Close On Exit modes. Default is to close 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]
2002-10-23 14:21:12 +00:00
}
Introduce a typedef for frontend handles. This is another major source of unexplained 'void *' parameters throughout the code. In particular, the currently unused testback.c actually gave the wrong pointer type to its internal store of the frontend handle - it cast the input void * to a Terminal *, from which it got implicitly cast back again when calling from_backend, and nobody noticed. Now it uses the right type internally as well as externally.
2018-09-12 08:10:51 +00:00
static void exit_callback(void *vctx)
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)vctx;
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
int exitcode, close_on_exit;
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
Various error-handling fixes, mostly in Unix PuTTY but one (failure to save a session) crosses over into the platform-independent side. [originally from svn r3041]
2003-04-01 18:10:25 +00:00
if (!inst->exited &&
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
(exitcode = backend_exitcode(inst->backend)) >= 0) {
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
destroy_inst_connection(inst);
GTK: add a delete_inst() function to clean up a gui_data. This has been logically necessary in principle for ages, but we got away without it because we just exited the program. But in the multi- window GtkApplication front ends, we can't get away with that for ever; we need to be able to free _one_ of our 'struct gui_data' instances and everything dangling off it (or, at least, everything that GTK's reference counting system doesn't clean up for us), without also doing anything global to the process in which that gui_data is contained.
2017-11-26 11:50:49 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
close_on_exit = conf_get_int(inst->conf, CONF_close_on_exit);
if (close_on_exit == FORCE_ON ||
(close_on_exit == AUTO && exitcode == 0)) {
GTK: add a delete_inst() function to clean up a gui_data. This has been logically necessary in principle for ages, but we got away without it because we just exited the program. But in the multi- window GtkApplication front ends, we can't get away with that for ever; we need to be able to free _one_ of our 'struct gui_data' instances and everything dangling off it (or, at least, everything that GTK's reference counting system doesn't clean up for us), without also doing anything global to the process in which that gui_data is contained.
2017-11-26 11:50:49 +00:00
gtk_widget_destroy(inst->window);
}
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
}
Avoid freeing the backend in notify_remote_exit(), since that's 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]
2008-11-17 18:36:27 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void gtk_seat_notify_remote_exit(Seat *seat)
Avoid freeing the backend in notify_remote_exit(), since that's 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]
2008-11-17 18:36:27 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Revamp GTK's session close handling using toplevel callbacks. Instead of having a special GTK idle function for dealing with session closing, I now use the new top-level callback mechanism which is slightly simpler for calling a one-off function. Also in this commit, I've arranged for connection_fatal to queue a call to the same session close function after displaying the message box, with the effect that now all the same processing takes place no matter whether the session closes cleanly or uncleanly - e.g. the SSH specials submenu is cleaned out, as it should be. [originally from svn r10022]
2013-08-17 16:06:22 +00:00
queue_toplevel_callback(exit_callback, inst);
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
}
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void destroy_inst_connection(GtkFrontend *inst)
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->exited = true;
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
if (inst->ldisc) {
ldisc_free(inst->ldisc);
inst->ldisc = NULL;
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (inst->backend) {
backend_free(inst->backend);
inst->backend = NULL;
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
}
if (inst->term)
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
term_provide_backend(inst->term, NULL);
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
if (inst->menu) {
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
seat_update_specials_menu(&inst->seat);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_widget_set_sensitive(inst->restartitem, true);
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
}
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void delete_inst(GtkFrontend *inst)
GTK: add a delete_inst() function to clean up a gui_data. This has been logically necessary in principle for ages, but we got away without it because we just exited the program. But in the multi- window GtkApplication front ends, we can't get away with that for ever; we need to be able to free _one_ of our 'struct gui_data' instances and everything dangling off it (or, at least, everything that GTK's reference counting system doesn't clean up for us), without also doing anything global to the process in which that gui_data is contained.
2017-11-26 11:50:49 +00:00
{
Expand the dialog registering/unregistering system. Now it has several 'slots', each named for a particular class of subsidiary dialog box that a session window can have at most one of, and register_network_prompt_dialog has a more general name and takes an enum-typed argument identifying a slot. This lets me avoid writing a zillion annoyingly similar function pairs and corresponding snippets of cleanup code in delete_inst.
2017-11-26 16:51:19 +00:00
int dialog_slot;
for (dialog_slot = 0; dialog_slot < DIALOG_SLOT_LIMIT; dialog_slot++) {
if (inst->dialogs[dialog_slot]) {
gtk_widget_destroy(inst->dialogs[dialog_slot]);
inst->dialogs[dialog_slot] = NULL;
}
GTK: system for not leaving stale network prompt dialogs. When I switch verify_ssh_host_key() and friends over to creating non-modal message boxes and returning to the main loop, there will be a risk that their parent window will need to close for some other reason while the user hasn't answered the pending question yet. (E.g. if the user presses the main session window's close button, which will no longer be a prohibited UI action once the transient dialog is not modal.) At that point we need to get rid of the pending dialog box, both for UI purposes (it would look silly and be confusing to leave it lying around) and for memory management (if the user subsequently clicks OK in such a dialog it would probably try to leave its result somewhere stale). So now there's a mechanism for gtkwin.c remembering what the current 'network prompt dialog' is, if any (in which category I intend to include everything triggered from ssh.c's various reasons for asking crypto-related questions), and cleaning it up when the struct gui_data it belongs to goes away.
2017-11-26 14:55:15 +00:00
}
GTK: add a delete_inst() function to clean up a gui_data. This has been logically necessary in principle for ages, but we got away without it because we just exited the program. But in the multi- window GtkApplication front ends, we can't get away with that for ever; we need to be able to free _one_ of our 'struct gui_data' instances and everything dangling off it (or, at least, everything that GTK's reference counting system doesn't clean up for us), without also doing anything global to the process in which that gui_data is contained.
2017-11-26 11:50:49 +00:00
if (inst->window) {
gtk_widget_destroy(inst->window);
inst->window = NULL;
}
if (inst->menu) {
gtk_widget_destroy(inst->menu);
inst->menu = NULL;
}
Make connection_fatal() nonmodal. This change requires me to break up the general cleanups in delete_inst() into two halves: one runs when the error message box is created, and cleans up the network connection and all the stuff associated with it, and the other runs when the error message is dismissed and the window can actually close.
2017-11-26 19:59:24 +00:00
destroy_inst_connection(inst);
GTK: add a delete_inst() function to clean up a gui_data. This has been logically necessary in principle for ages, but we got away without it because we just exited the program. But in the multi- window GtkApplication front ends, we can't get away with that for ever; we need to be able to free _one_ of our 'struct gui_data' instances and everything dangling off it (or, at least, everything that GTK's reference counting system doesn't clean up for us), without also doing anything global to the process in which that gui_data is contained.
2017-11-26 11:50:49 +00:00
if (inst->term) {
term_free(inst->term);
inst->term = NULL;
}
if (inst->conf) {
conf_free(inst->conf);
inst->conf = NULL;
}
if (inst->logctx) {
log_free(inst->logctx);
inst->logctx = NULL;
}
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
#if GTK_CHECK_VERSION(2,0,0)
if (inst->trust_sigil_pb) {
g_object_unref(G_OBJECT(inst->trust_sigil_pb));
inst->trust_sigil_pb = NULL;
}
#else
if (inst->trust_sigil_pm) {
gdk_pixmap_unref(inst->trust_sigil_pm);
inst->trust_sigil_pm = NULL;
}
#endif
Change order of cleanup in delete_inst. If you close a session window with an associated SSH back end, the back end may call back to notify_remote_exit() from ssh_free(), which queues a new top-level callback citing the inst structure we were about to delete. We could fix this by introducing a special 'moribund' flag which inhibits notify_remote_exit from queueing a callback, but far easier is to move the delete_callbacks_for_context() call to _after_ all subsidiary things have been cleaned up, so that any last-minute callbacks they might schedule will be promptly unscheduled again before they do any damage.
2017-11-26 15:35:25 +00:00
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
/*
* Clear up any in-flight clipboard_data_instances. We can't
* actually _free_ them, but we detach them from the inst that's
* about to be destroyed.
*/
while (inst->cdi_headtail.next != &inst->cdi_headtail) {
struct clipboard_data_instance *cdi = inst->cdi_headtail.next;
cdi->state = NULL;
cdi->next->prev = cdi->prev;
cdi->prev->next = cdi->next;
cdi->next = cdi->prev = cdi;
}
#endif
Change order of cleanup in delete_inst. If you close a session window with an associated SSH back end, the back end may call back to notify_remote_exit() from ssh_free(), which queues a new top-level callback citing the inst structure we were about to delete. We could fix this by introducing a special 'moribund' flag which inhibits notify_remote_exit from queueing a callback, but far easier is to move the delete_callbacks_for_context() call to _after_ all subsidiary things have been cleaned up, so that any last-minute callbacks they might schedule will be promptly unscheduled again before they do any damage.
2017-11-26 15:35:25 +00:00
/*
* Delete any top-level callbacks associated with inst, which
* would otherwise become stale-pointer dereferences waiting to
* happen. We do this last, because some of the above cleanups
* (notably shutting down the backend) might themelves queue such
* callbacks, so we need to make sure they don't do that _after_
* we're supposed to have cleaned everything up.
*/
delete_callbacks_for_context(inst);
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlogstuff_free(inst->eventlogstuff);
GTK: add a delete_inst() function to clean up a gui_data. This has been logically necessary in principle for ages, but we got away without it because we just exited the program. But in the multi- window GtkApplication front ends, we can't get away with that for ever; we need to be able to free _one_ of our 'struct gui_data' instances and everything dangling off it (or, at least, everything that GTK's reference counting system doesn't clean up for us), without also doing anything global to the process in which that gui_data is contained.
2017-11-26 11:50:49 +00:00
sfree(inst);
}
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
void destroy(GtkWidget *widget, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
GTK: add a delete_inst() function to clean up a gui_data. This has been logically necessary in principle for ages, but we got away without it because we just exited the program. But in the multi- window GtkApplication front ends, we can't get away with that for ever; we need to be able to free _one_ of our 'struct gui_data' instances and everything dangling off it (or, at least, everything that GTK's reference counting system doesn't clean up for us), without also doing anything global to the process in which that gui_data is contained.
2017-11-26 11:50:49 +00:00
inst->window = NULL;
delete_inst(inst);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
session_window_closed();
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
}
gint focus_event(GtkWidget *widget, GdkEventFocus *event, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Slight improvement to cursor blink timing: since the cursor doesn't blink when the window doesn't have focus, we don't schedule blink timers at that point either. Infrastructure change: term->has_focus should now not be written directly from outside terminal.c. Instead, use the function term_set_focus, which will sort out the blink timers as well. [originally from svn r4911]
2004-11-27 19:34:45 +00:00
term_set_focus(inst->term, event->in);
Reorganised the Unicode layer somewhat: moved luni_send and 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]
2002-10-26 11:08:59 +00:00
term_update(inst->term);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
show_mouseptr(inst, true);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void gtk_seat_set_busy_status(Seat *seat, BusyStatus status)
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
inst->busy_status = status;
update_mouseptr(inst);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void gtkwin_set_raw_mouse_mode(TermWin *tw, bool activate)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Make send_raw_mouse a field of GtkFrontend. I came across this unexplained static variable in my boolification trawl. It seems clearly unintentional that it has only one instance instead of one per terminal window - the code in question closely resembles the Windows front end, and I think this must just be a variable that I never swept up into 'inst' in the very early days when I was making gtkwin.c out of a cloned-and-hacked window.c in the first place. These days it's even a bug, now that the OS X port actually does run multiple terminal windows in the same process: if one goes into mouse reporting mode, I'm pretty sure this would have done confusing things to the effects of mouse actions in the other.
2018-11-03 08:17:44 +00:00
inst->send_raw_mouse = activate;
Decouple frontend's raw mouse mode from pointer shape. This paves the way for a followup commit that will make them happen at slightly different times.
2021-02-07 19:59:21 +00:00
}
static void gtkwin_set_raw_mouse_mode_pointer(TermWin *tw, bool activate)
{
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
inst->pointer_indicates_raw_mouse = activate;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
update_mouseptr(inst);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
GTK: stop using geometry-based window sizing functions. 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.
2016-04-04 10:24:24 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void compute_whole_window_size(GtkFrontend *inst,
GTK: stop using geometry-based window sizing functions. 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.
2016-04-04 10:24:24 +00:00
int wchars, int hchars,
int *wpix, int *hpix);
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
static void gtkwin_deny_term_resize(void *vctx)
{
GtkFrontend *inst = (GtkFrontend *)vctx;
GTK: fix font-size change when window maximised. If you maximise the terminal window and then press Ctrl-> or Ctrl-< to change the font size, then the maximised window can't change size, so what _should_ happen instead is that the terminal adjusts the number of character cells to whatever the new font size will now permit in the same size of window as before. But in fact, the terminal size wasn't changing at all, because the call to gtkwin_request_resize (called from change_font_size) detected the maximised window and went straight to gtkwin_deny_term_resize, which immediately called term_size() to tell the terminal it still had the same size as before. This commit switches gtkwin_deny_term_resize so that instead it calls drawing_area_setup_simple(), which re-runs drawing_area_setup with the same size the drawing area already had. This should work out the same in the case where we're _not_ changing the font size, but now also does the right thing when we are.
2022-02-03 17:48:21 +00:00
drawing_area_setup_simple(inst);
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
}
Fix a compile warning when building with GTK 1. gtkwin_deny_term_resize() is unused in a GTK1 build, triggering an 'unused static function' compiler warning.
2024-11-28 18:31:43 +00:00
#endif
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
Move window resize timeouts into the GTK frontend. In the changes around commit 420fe75552afa94, I made the terminal suspend output processing while it waited for a term_size() callback in response to a resize request. Because on X11 there are unusual circumstances in which you never receive that callback, I also added a last-ditch 5-second timeout, so that eventually we'll resume terminal output processing regardless. But the timeout lives in terminal.c, in the cross-platform code. This is pointless on Windows (where resize processing is synchronous, so we always finish it before the timer code next gets called anyway), but I decided it was easier to keep the whole mechanism in terminal.c in the absence of a good reason not to. Now I've found that reason. We _also_ generate window resizes locally to the GTK front end, in response to the key combinations that change the font size, and _those_ still have an asynchrony problem. So, to begin with, I'm refactoring the request_resize system so that now there's an explicit callback from the frontend to the terminal to say 'Your resize request has now been processed, whether or not you've received a term_size() call'. On Windows, this simplifies matters greatly because we always know exactly when to call that, and don't have to keep a 'have we called term_size() already?' flag. On GTK, the timing complexity previously in terminal.c has moved into window.c. No functional change (I hope). The payoff will be in the next commit.
2022-05-12 17:16:56 +00:00
static void gtkwin_timer(void *vctx, unsigned long now)
{
GtkFrontend *inst = (GtkFrontend *)vctx;
if (inst->win_resize_pending && now == inst->win_resize_timeout) {
if (inst->term_resize_notification_required)
term_resize_request_completed(inst->term);
inst->win_resize_pending = false;
}
}
GTK: don't try to change font size in mid-window-resize. If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
2022-05-12 18:38:45 +00:00
static void request_resize_internal(GtkFrontend *inst, bool from_terminal,
int w, int h)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
GTK: avoid trying to resize a maximised window. This is another thing that seems harmless on X11 but causes window redraws to semipermanently stop happening on Wayland: if we try to gtk_window_resize() a window that is maximised at the time, then something mysterious goes wrong and we stop ever getting "draw" events.
2021-12-18 14:14:16 +00:00
#if GTK_CHECK_VERSION(2,0,0)
/*
* Initial check: don't even try to resize a window if it's in one
* of the states that make that impossible. This includes being
* maximised; being full-screen (if we ever implement that); or
* being in various tiled states.
*
* On X11, the effect of trying to resize the window when it can't
* be resized should be that the window manager sends us a
* synthetic ConfigureNotify event restating our existing size
* (ICCCM section 4.1.5 "Configuring the Window"). That's awkward
* to deal with, but not impossible; so for X11 alone, we might
* not bother with this check.
*
* (In any case, X11 has other reasons why a window resize might
* be rejected, which this enumeration can't be aware of in any
* case. For example, if your window manager is a tiling one, then
* all your windows are _de facto_ tiled, but not _de jure_ in a
* way that GDK will know about. So we have to handle those
* synthetic ConfigureNotifies in any case.)
*
* On Wayland, as of GTK 3.24.20, the effects are much worse: it
* looks to me as if GTK stops ever sending us "draw" events, or
* even a size_allocate, so the display locks up completely until
* you toggle the maximised state of the window by some other
* means. So it's worth checking!
*/
GdkWindow *gdkwin = gtk_widget_get_window(inst->window);
if (gdkwin) {
GdkWindowState state = gdk_window_get_state(gdkwin);
if (state & (GDK_WINDOW_STATE_MAXIMIZED |
GDK_WINDOW_STATE_FULLSCREEN |
Fix build with GTK3 prior to 3.22.23. Those versions of GTK (or rather, GDK) don't support the GDK_WINDOW_STATE_TOP_TILED constants; they only support the non-directional GDK_WINDOW_STATE_TILED. And GTK < 3.10.0 doesn't even support that. All those constants were under #ifdef already; I've just made the ifdefs a bit more precise.
2022-10-22 06:46:44 +00:00
#if GTK_CHECK_VERSION(3,10,0)
GTK: avoid trying to resize a maximised window. This is another thing that seems harmless on X11 but causes window redraws to semipermanently stop happening on Wayland: if we try to gtk_window_resize() a window that is maximised at the time, then something mysterious goes wrong and we stop ever getting "draw" events.
2021-12-18 14:14:16 +00:00
GDK_WINDOW_STATE_TILED |
Fix build with GTK3 prior to 3.22.23. Those versions of GTK (or rather, GDK) don't support the GDK_WINDOW_STATE_TOP_TILED constants; they only support the non-directional GDK_WINDOW_STATE_TILED. And GTK < 3.10.0 doesn't even support that. All those constants were under #ifdef already; I've just made the ifdefs a bit more precise.
2022-10-22 06:46:44 +00:00
#endif
#if GTK_CHECK_VERSION(3,22,23)
GTK: avoid trying to resize a maximised window. This is another thing that seems harmless on X11 but causes window redraws to semipermanently stop happening on Wayland: if we try to gtk_window_resize() a window that is maximised at the time, then something mysterious goes wrong and we stop ever getting "draw" events.
2021-12-18 14:14:16 +00:00
GDK_WINDOW_STATE_TOP_TILED |
GDK_WINDOW_STATE_RIGHT_TILED |
GDK_WINDOW_STATE_BOTTOM_TILED |
GDK_WINDOW_STATE_LEFT_TILED |
#endif
0)) {
Try to ensure term_size() after win_resize_request(). 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.
2021-12-19 10:21:11 +00:00
queue_toplevel_callback(gtkwin_deny_term_resize, inst);
GTK: fix crash changing font size when terminal maximised. When I maximised a terminal window today and then used Ctrl-< to reduce its font size (expecting that the window size would stay the same but more characters would be squeezed in), pterm failed the assertion in term_request_resize_completed() that checks term->win_resize_pending == WIN_RESIZE_AWAIT_REPLY. This happened because in this situation request_resize_internal() was called from within window.c rather than from within the terminal code itself. So the terminal didn't know a resize is pending at all, and was surprised to be told that one had finished. request_resize_internal() already has a flag parameter to tell it whether a given resize came from the terminal or not. On the main code path, that flag is used to decide whether to notify the terminal. But on the early exit path when the window is maximised, we weren't checking the flag. An easy fix.
2022-12-04 11:50:08 +00:00
if (from_terminal)
term_resize_request_completed(inst->term);
GTK: avoid trying to resize a maximised window. This is another thing that seems harmless on X11 but causes window redraws to semipermanently stop happening on Wayland: if we try to gtk_window_resize() a window that is maximised at the time, then something mysterious goes wrong and we stop ever getting "draw" events.
2021-12-18 14:14:16 +00:00
return;
}
}
#endif
Use new GTK3 API call for server-controlled window resize. gtk_window_resize_to_geometry() allows us to make use of the already- set-up WM resize hints to immediately figure out how to resize the window to a particular character cell size, and hence makes a much simpler implementation of request_resize() than the previous hackery.
2015-08-24 17:59:13 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Use the appalling gnome-terminal hack for server-controlled resizes 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]
2002-10-15 16:24:42 +00:00
int large_x, large_y;
int offset_x, offset_y;
int area_x, area_y;
GtkRequisition inner, outer;
/*
* This is a heinous hack dreamed up by the gnome-terminal
* people to get around a limitation in gtk. The problem is
* that in order to set the size correctly we really need to be
* calling gtk_window_resize - but that needs to know the size
* of the _whole window_, not the drawing area. So what we do
* is to set an artificially huge size request on the drawing
* area, recompute the resulting size request on the window,
* and look at the difference between the two. That gives us
* the x and y offsets we need to translate drawing area size
* into window size for real, and then we call
* gtk_window_resize.
*/
/*
* We start by retrieving the current size of the whole window.
* Adding a bit to _that_ will give us a value we can use as a
* bogus size request which guarantees to be bigger than the
* current size of the drawing area.
*/
Restore ability to build with Gtk<3. This got broken in 696550a5f2.
2021-04-05 16:05:10 +00:00
get_window_pixel_size(inst, &large_x, &large_y);
Use the appalling gnome-terminal hack for server-controlled resizes 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]
2002-10-15 16:24:42 +00:00
large_x += 32;
large_y += 32;
gtk_widget_set_size_request(inst->area, large_x, large_y);
gtk_widget_size_request(inst->area, &inner);
gtk_widget_size_request(inst->window, &outer);
offset_x = outer.width - inner.width;
offset_y = outer.height - inner.height;
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
area_x = inst->font_width * w + 2*inst->window_border;
area_y = inst->font_height * h + 2*inst->window_border;
Use the appalling gnome-terminal hack for server-controlled resizes 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]
2002-10-15 16:24:42 +00:00
/*
* Now we must set the size request on the drawing area back to
* something sensible before we commit the real resize. Best
* way to do this, I think, is to set it to what the size is
* really going to end up being.
*/
gtk_widget_set_size_request(inst->area, area_x, area_y);
Use gtkcompat.h to slim down a few ifdefs. Now that I've got a general place to centralise handling of at least the simple differences between GTK 1 and 2, I should use it wherever possible. So this commit removes just a small number of ifdefs which are either obsoleted by definitions already in gtkcompat.h (like set_size_request vs set_usize), or can easily be replaced by adding another (e.g. gtk_color_selection_set_has_opacity_control).
2015-08-09 08:59:25 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
gtk_window_resize(GTK_WINDOW(inst->window),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
area_x + offset_x, area_y + offset_y);
Use the appalling gnome-terminal hack for server-controlled resizes 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]
2002-10-15 16:24:42 +00:00
#else
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
gtk_drawing_area_size(GTK_DRAWING_AREA(inst->area), area_x, area_y);
I give up. I can't work out what the purpose of the call to 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]
2008-03-29 20:02:12 +00:00
/*
* I can no longer remember what this call to
* gtk_container_dequeue_resize_handler is for. It was
* introduced in r3092 with no comment, and the commit log
* message was uninformative. I'm _guessing_ its purpose is to
* prevent gratuitous resize processing on the window given
* that we're about to resize it anyway, but I have no idea
* why that's so incredibly vital.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
I give up. I can't work out what the purpose of the call to 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]
2008-03-29 20:02:12 +00:00
* I've tried removing the call, and nothing seems to go
* wrong. I've backtracked to r3092 and tried removing the
* call there, and still nothing goes wrong. So I'm going to
* adopt the working hypothesis that it's superfluous; I won't
* actually remove it from the GTK 1.2 code, but I won't
* attempt to replicate its functionality in the GTK 2 code
* above.
*/
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
gtk_container_dequeue_resize_handler(GTK_CONTAINER(inst->window));
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
gdk_window_resize(gtk_widget_get_window(inst->window),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
area_x + offset_x, area_y + offset_y);
Use the appalling gnome-terminal hack for server-controlled resizes 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]
2002-10-15 16:24:42 +00:00
#endif
Use new GTK3 API call for server-controlled window resize. gtk_window_resize_to_geometry() allows us to make use of the already- set-up WM resize hints to immediately figure out how to resize the window to a particular character cell size, and hence makes a much simpler implementation of request_resize() than the previous hackery.
2015-08-24 17:59:13 +00:00
#else /* GTK_CHECK_VERSION(3,0,0) */
GTK: stop using geometry-based window sizing functions. 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.
2016-04-04 10:24:24 +00:00
int wp, hp;
compute_whole_window_size(inst, w, h, &wp, &hp);
gtk_window_resize(GTK_WINDOW(inst->window), wp, hp);
Use new GTK3 API call for server-controlled window resize. gtk_window_resize_to_geometry() allows us to make use of the already- set-up WM resize hints to immediately figure out how to resize the window to a particular character cell size, and hence makes a much simpler implementation of request_resize() than the previous hackery.
2015-08-24 17:59:13 +00:00
#endif
Move window resize timeouts into the GTK frontend. In the changes around commit 420fe75552afa94, I made the terminal suspend output processing while it waited for a term_size() callback in response to a resize request. Because on X11 there are unusual circumstances in which you never receive that callback, I also added a last-ditch 5-second timeout, so that eventually we'll resume terminal output processing regardless. But the timeout lives in terminal.c, in the cross-platform code. This is pointless on Windows (where resize processing is synchronous, so we always finish it before the timer code next gets called anyway), but I decided it was easier to keep the whole mechanism in terminal.c in the absence of a good reason not to. Now I've found that reason. We _also_ generate window resizes locally to the GTK front end, in response to the key combinations that change the font size, and _those_ still have an asynchrony problem. So, to begin with, I'm refactoring the request_resize system so that now there's an explicit callback from the frontend to the terminal to say 'Your resize request has now been processed, whether or not you've received a term_size() call'. On Windows, this simplifies matters greatly because we always know exactly when to call that, and don't have to keep a 'have we called term_size() already?' flag. On GTK, the timing complexity previously in terminal.c has moved into window.c. No functional change (I hope). The payoff will be in the next commit.
2022-05-12 17:16:56 +00:00
inst->win_resize_pending = true;
GTK: don't try to change font size in mid-window-resize. If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
2022-05-12 18:38:45 +00:00
inst->term_resize_notification_required = from_terminal;
Move window resize timeouts into the GTK frontend. In the changes around commit 420fe75552afa94, I made the terminal suspend output processing while it waited for a term_size() callback in response to a resize request. Because on X11 there are unusual circumstances in which you never receive that callback, I also added a last-ditch 5-second timeout, so that eventually we'll resume terminal output processing regardless. But the timeout lives in terminal.c, in the cross-platform code. This is pointless on Windows (where resize processing is synchronous, so we always finish it before the timer code next gets called anyway), but I decided it was easier to keep the whole mechanism in terminal.c in the absence of a good reason not to. Now I've found that reason. We _also_ generate window resizes locally to the GTK front end, in response to the key combinations that change the font size, and _those_ still have an asynchrony problem. So, to begin with, I'm refactoring the request_resize system so that now there's an explicit callback from the frontend to the terminal to say 'Your resize request has now been processed, whether or not you've received a term_size() call'. On Windows, this simplifies matters greatly because we always know exactly when to call that, and don't have to keep a 'have we called term_size() already?' flag. On GTK, the timing complexity previously in terminal.c has moved into window.c. No functional change (I hope). The payoff will be in the next commit.
2022-05-12 17:16:56 +00:00
inst->win_resize_timeout = schedule_timer(
WIN_RESIZE_TIMEOUT, gtkwin_timer, inst);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
GTK: don't try to change font size in mid-window-resize. If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
2022-05-12 18:38:45 +00:00
static void gtkwin_request_resize(TermWin *tw, int w, int h)
{
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
request_resize_internal(inst, true, w, h);
}
Stop using GTK3-deprecated gdk_window_set_background(). We now have to use gdk_window_set_background_rgba(), having first set up an appropriate GdkRGBA structure.
2015-08-22 13:11:45 +00:00
#if GTK_CHECK_VERSION(3,0,0)
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
char *colour_to_css(const GdkColor *col)
{
Stop using GTK3-deprecated gdk_window_set_background(). We now have to use gdk_window_set_background_rgba(), having first set up an appropriate GdkRGBA structure.
2015-08-22 13:11:45 +00:00
GdkRGBA rgba;
rgba.red = col->red / 65535.0;
rgba.green = col->green / 65535.0;
rgba.blue = col->blue / 65535.0;
rgba.alpha = 1.0;
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
return gdk_rgba_to_string(&rgba);
}
#endif
void set_gtk_widget_background(GtkWidget *widget, const GdkColor *col)
{
#if GTK_CHECK_VERSION(3,0,0)
GtkCssProvider *provider = gtk_css_provider_new();
char *col_css = colour_to_css(col);
char *data = dupprintf(
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"#drawing-area, #top-level { background-color: %s; }\n", col_css);
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
gtk_css_provider_load_from_data(provider, data, -1, NULL);
GtkStyleContext *context = gtk_widget_get_style_context(widget);
gtk_style_context_add_provider(context, GTK_STYLE_PROVIDER(provider),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
free(data);
free(col_css);
Stop using GTK3-deprecated gdk_window_set_background(). We now have to use gdk_window_set_background_rgba(), having first set up an appropriate GdkRGBA structure.
2015-08-22 13:11:45 +00:00
#else
Fix thinko introduced in 8833634f4. This prevented compilation with Gtk 2.
2017-04-30 10:01:13 +00:00
if (gtk_widget_get_window(widget)) {
Compile fixes for GTK1 after recent work. 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!
2015-08-25 18:50:23 +00:00
/* For GTK1, which doesn't have a 'const' on
* gdk_window_set_background's second parameter type. */
GdkColor col_mutable = *col;
Fix thinko introduced in 8833634f4. This prevented compilation with Gtk 2.
2017-04-30 10:01:13 +00:00
gdk_window_set_background(gtk_widget_get_window(widget), &col_mutable);
Compile fixes for GTK1 after recent work. 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!
2015-08-25 18:50:23 +00:00
}
Stop using GTK3-deprecated gdk_window_set_background(). We now have to use gdk_window_set_background_rgba(), having first set up an appropriate GdkRGBA structure.
2015-08-22 13:11:45 +00:00
#endif
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void set_window_background(GtkFrontend *inst)
Fix the nasty flashing-light-grey-on-resize problem, after MCV helpfully alerted me to the existence of gdk_window_set_background(). [originally from svn r2129]
2002-10-25 11:58:59 +00:00
{
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
if (inst->area)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
set_gtk_widget_background(GTK_WIDGET(inst->area), &inst->cols[258]);
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
if (inst->window)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
set_gtk_widget_background(GTK_WIDGET(inst->window), &inst->cols[258]);
Fix the nasty flashing-light-grey-on-resize problem, after MCV helpfully alerted me to the existence of gdk_window_set_background(). [originally from svn r2129]
2002-10-25 11:58:59 +00:00
}
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
static void gtkwin_palette_set(TermWin *tw, unsigned start, unsigned ncolours,
const rgb *colours)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
assert(start <= OSC4_NCOLOURS);
assert(ncolours <= OSC4_NCOLOURS - start);
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 10:21:35 +00:00
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 10:21:35 +00:00
if (!inst->colmap) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->colmap = gdk_colormap_get_system();
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 10:21:35 +00:00
} else {
Bring some order to colour palette indexing. There are three separate indexing schemes in use by various bits of the PuTTY front ends, and _none_ of them was clearly documented, let alone all in the same place. Worse, functions that looked obviously related, like win_palette_set and win_palette_get, used different encodings. Now all the encodings are defined together in putty.h, with explanation of why there are three in the first place and clear documentation of where each one is used; terminal.c provides mapping tables that convert between them; the terminology is consistent throughout; and win_palette_set has been converted to use the sensible encoding.
2021-02-07 19:59:20 +00:00
gdk_colormap_free_colors(inst->colmap, inst->cols, OSC4_NCOLOURS);
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 10:21:35 +00:00
}
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
#endif
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 10:21:35 +00:00
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
for (unsigned i = 0; i < ncolours; i++) {
const rgb *in = &colours[i];
GdkColor *out = &inst->cols[start + i];
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 10:21:35 +00:00
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
out->red = in->r * 0x0101;
out->green = in->g * 0x0101;
out->blue = in->b * 0x0101;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
}
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
{
Bring some order to colour palette indexing. There are three separate indexing schemes in use by various bits of the PuTTY front ends, and _none_ of them was clearly documented, let alone all in the same place. Worse, functions that looked obviously related, like win_palette_set and win_palette_get, used different encodings. Now all the encodings are defined together in putty.h, with explanation of why there are three in the first place and clear documentation of where each one is used; terminal.c provides mapping tables that convert between them; the terminology is consistent throughout; and win_palette_set has been converted to use the sensible encoding.
2021-02-07 19:59:20 +00:00
gboolean success[OSC4_NCOLOURS];
Fix palette-related segfault with Gtk<3. This was introduced in ca9cd983e1.
2021-04-05 15:59:58 +00:00
gdk_colormap_alloc_colors(inst->colmap, inst->cols + start,
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
ncolours, false, true, success);
for (unsigned i = 0; i < ncolours; i++) {
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
if (!success[i])
g_error("%s: couldn't allocate colour %d (#%02x%02x%02x)\n",
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
appname, start + i,
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
conf_get_int_int(inst->conf, CONF_colours, i*3+0),
conf_get_int_int(inst->conf, CONF_colours, i*3+1),
conf_get_int_int(inst->conf, CONF_colours, i*3+2));
}
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 10:21:35 +00:00
}
GTK3 port: condition out all uses of GdkColormap. The entire concept has gone away in GTK3, which assumes that everyone is now using modern true-colour video modes and so there's no longer any reason you shouldn't just casually make up any RGB triple you like without bothering to ask the display system's permission.
2015-08-16 13:22:14 +00:00
#endif
Fix the nasty flashing-light-grey-on-resize problem, after MCV helpfully alerted me to the existence of gdk_window_set_background(). [originally from svn r2129]
2002-10-25 11:58:59 +00:00
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
if (start <= OSC4_COLOUR_bg && OSC4_COLOUR_bg < start + ncolours) {
/* Default Background has changed, so ensure that space between text
* area and window border is refreshed. */
set_window_background(inst);
if (inst->area && gtk_widget_get_window(inst->area)) {
draw_backing_rect(inst);
gtk_widget_queue_draw(inst->area);
}
Equivalent of r6583 window-border palette-change fix for Gtk. [originally from svn r6609] [r6583 == f9c1d0acf83e8cd73afa905b5d85bcdae9c311eb]
2006-03-12 22:17:46 +00:00
}
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Make TermWin's palette_get_overrides() take a Terminal *. Less than 12 hours after 0.75 went out of the door, a user pointed out that enabling the 'Use system colours' config option causes an immediate NULL-dereference crash. The reason is because a chain of calls from term_init() ends up calling back to the Windows implementation of the palette_get_overrides() method, which responds by trying to call functions on the static variable 'term' in window.c, which won't be initialised until term_init() has returned. Simple fix: palette_get_overrides() is now given a pointer to the Terminal that it should be updating, because it can't find it out any other way.
2021-05-08 17:13:06 +00:00
static void gtkwin_palette_get_overrides(TermWin *tw, Terminal *term)
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
{
/* GTK has no analogue of Windows's 'standard system colours', so GTK PuTTY
* has no config option to override the normally configured colours from
* it */
}
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
static struct clipboard_state *clipboard_from_atom(
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst, GdkAtom atom)
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
{
int i;
for (i = 0; i < N_CLIPBOARDS; i++) {
struct clipboard_state *state = &inst->clipstates[i];
if (state->inst == inst && state->atom == atom)
return state;
}
return NULL;
}
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
/* ----------------------------------------------------------------------
* Clipboard handling, using the high-level GtkClipboard interface in
* as hands-off a way as possible. We write and read the clipboard as
* UTF-8 text, and let GTK deal with converting to any other text
* formats it feels like.
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
*/
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void set_clipboard_atom(GtkFrontend *inst, int clipboard, GdkAtom atom)
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
{
struct clipboard_state *state = &inst->clipstates[clipboard];
state->inst = inst;
state->clipboard = clipboard;
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
state->atom = atom;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
if (state->atom != GDK_NONE) {
state->gtkclipboard = gtk_clipboard_get_for_display(
gdk_display_get_default(), state->atom);
g_object_set_data(G_OBJECT(state->gtkclipboard), "user-data", state);
} else {
state->gtkclipboard = NULL;
}
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
int init_clipboard(GtkFrontend *inst)
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
{
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
set_clipboard_atom(inst, CLIP_PRIMARY, GDK_SELECTION_PRIMARY);
GTK1 build fixes. Looks as if I haven't retried the GTK1 build for a while, and recent GTK frontend development has broken it. The selection revamp has pointed out that GTK1 didn't have the accessor function gtk_selection_data_get_selection(), the standard GdkAtom value GDK_SELECTION_CLIPBOARD, or keysyms for alphabetic characters; and also I had an initialisation of one of my own structure fields (dp->selparams) accidentally not guarded by the same GTK-versioning ifdef that controls whether or not it was defined.
2018-03-03 18:18:54 +00:00
set_clipboard_atom(inst, CLIP_CLIPBOARD, clipboard_atom);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
}
static void clipboard_provide_data(GtkClipboard *clipboard,
GtkSelectionData *selection_data,
guint info, gpointer data)
{
struct clipboard_data_instance *cdi =
(struct clipboard_data_instance *)data;
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
if (cdi->state && cdi->state->current_cdi == cdi) {
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
gtk_selection_data_set_text(selection_data, cdi->pasteout_data_utf8,
cdi->pasteout_data_utf8_len);
}
}
static void clipboard_clear(GtkClipboard *clipboard, gpointer data)
{
struct clipboard_data_instance *cdi =
(struct clipboard_data_instance *)data;
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
if (cdi->state && cdi->state->current_cdi == cdi) {
if (cdi->state->inst && cdi->state->inst->term) {
term_lost_clipboard_ownership(cdi->state->inst->term,
cdi->state->clipboard);
}
cdi->state->current_cdi = NULL;
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
}
sfree(cdi->pasteout_data_utf8);
Fix linked-list mismanagement. Oh dear. I have no excuse.
2017-12-17 20:43:44 +00:00
cdi->next->prev = cdi->prev;
cdi->prev->next = cdi->next;
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
sfree(cdi);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_clip_write(
TermWin *tw, int clipboard, wchar_t *data, int *attr,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
truecolour *truecolour, int len, bool must_deselect)
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state *state = &inst->clipstates[clipboard];
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
struct clipboard_data_instance *cdi;
if (inst->direct_to_font) {
/* In this clipboard mode, we just can't paste if we're in
* direct-to-font mode. Fortunately, that shouldn't be
* important, because we'll only use this clipboard handling
* code on systems where that kind of font doesn't exist
* anyway. */
return;
}
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
if (!state->gtkclipboard)
return;
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
cdi = snew(struct clipboard_data_instance);
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
cdi->state = state;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
state->current_cdi = cdi;
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
cdi->pasteout_data_utf8 = snewn(len*6, char);
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
cdi->prev = inst->cdi_headtail.prev;
cdi->next = &inst->cdi_headtail;
cdi->next->prev = cdi;
cdi->prev->next = cdi;
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
{
const wchar_t *tmp = data;
int tmplen = len;
cdi->pasteout_data_utf8_len =
charset_from_unicode(&tmp, &tmplen, cdi->pasteout_data_utf8,
len*6, CS_UTF8, NULL, NULL, 0);
}
/*
* It would be nice to just call gtk_clipboard_set_text() in place
* of all of the faffing below. Unfortunately, that won't give me
* access to the clipboard-clear event, which we use to visually
* deselect text in the terminal.
*/
{
GtkTargetList *targetlist;
GtkTargetEntry *targettable;
gint n_targets;
targetlist = gtk_target_list_new(NULL, 0);
gtk_target_list_add_text_targets(targetlist, 0);
targettable = gtk_target_table_new_from_list(targetlist, &n_targets);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
gtk_clipboard_set_with_data(state->gtkclipboard, targettable,
n_targets, clipboard_provide_data,
clipboard_clear, cdi);
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
gtk_target_table_free(targettable, n_targets);
gtk_target_list_unref(targetlist);
}
}
static void clipboard_text_received(GtkClipboard *clipboard,
const gchar *text, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Stop front ends remembering the data of their last paste. Previously, both the Unix and Windows front ends would respond to a paste action by retrieving data from the system clipboard, converting it appropriately, _storing_ it in a persistent dynamic data block inside the front end, and then calling term_do_paste(term), which in turn would call back to the front end via get_clip() to retrieve the current contents of that stored data block. But, as far as I can tell, this was a completely pointless mechanism, because after a data block was written into this storage area, it would be immediately used for exactly one paste, and then never accessed again until the next paste action caused it to be freed and replaced with a new chunk of pasted data. So why on earth was it stored persistently at all, and why that callback mechanism from frontend to terminal back to frontend to retrieve it for the actual paste action? I have no idea. This change removes the entire system and replaces it with the completely obvious alternative: the character-set-converted version of paste data is allocated in a _local_ variable in the frontend paste functions, passed directly to term_do_paste which now takes (buffer,length) parameters, and freed immediately afterwards. get_clip() is gone.
2017-12-09 08:41:03 +00:00
wchar_t *paste;
Rework Unicode conversion APIs to use a BinarySink. The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs. This commit introduces a fresh pair of functions to replace them, which generate output by writing to a BinarySink. So it's now up to the caller to decide whether it wants the output written to a fixed-size buffer with overflow checking (via buffer_sink), or dynamically allocated, or even written directly to some other output channel. Nothing uses the new functions yet. I plan to migrate things over in upcoming commits. What was wrong with the old APIs: they had that awkward undocumented Windows-specific 'flags' parameter that I described in the previous commit and took out of the dup_X_to_Y wrappers. But much worse, the semantics for buffer overflow were not just undocumented but actually inconsistent. dup_wc_to_mb() in utils assumed that the underlying wc_to_mb would fill the buffer nearly full and return the size of data it wrote. In fact, this was untrue in the case where wc_to_mb called WideCharToMultiByte: that returns straight-up failure, setting the Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially fill the output buffer, but doesn't tell you how much it wrote! What's wrong with the new API: it's a bit awkward to write a sequence of wchar_t in native byte order to a byte-oriented BinarySink, so people using put_mb_to_wc directly have to do some annoying pointer casting. But I think that's less horrible than the previous APIs. Another change: in the new API for wc_to_mb, defchr can be "", but not NULL.
2024-09-24 07:18:48 +00:00
size_t paste_len;
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
if (!text)
return;
Rework Unicode conversion APIs to use a BinarySink. The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs. This commit introduces a fresh pair of functions to replace them, which generate output by writing to a BinarySink. So it's now up to the caller to decide whether it wants the output written to a fixed-size buffer with overflow checking (via buffer_sink), or dynamically allocated, or even written directly to some other output channel. Nothing uses the new functions yet. I plan to migrate things over in upcoming commits. What was wrong with the old APIs: they had that awkward undocumented Windows-specific 'flags' parameter that I described in the previous commit and took out of the dup_X_to_Y wrappers. But much worse, the semantics for buffer overflow were not just undocumented but actually inconsistent. dup_wc_to_mb() in utils assumed that the underlying wc_to_mb would fill the buffer nearly full and return the size of data it wrote. In fact, this was untrue in the case where wc_to_mb called WideCharToMultiByte: that returns straight-up failure, setting the Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially fill the output buffer, but doesn't tell you how much it wrote! What's wrong with the new API: it's a bit awkward to write a sequence of wchar_t in native byte order to a byte-oriented BinarySink, so people using put_mb_to_wc directly have to do some annoying pointer casting. But I think that's less horrible than the previous APIs. Another change: in the new API for wc_to_mb, defchr can be "", but not NULL.
2024-09-24 07:18:48 +00:00
paste = dup_mb_to_wc(CS_UTF8, text, length, &paste_len);
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
Stop front ends remembering the data of their last paste. Previously, both the Unix and Windows front ends would respond to a paste action by retrieving data from the system clipboard, converting it appropriately, _storing_ it in a persistent dynamic data block inside the front end, and then calling term_do_paste(term), which in turn would call back to the front end via get_clip() to retrieve the current contents of that stored data block. But, as far as I can tell, this was a completely pointless mechanism, because after a data block was written into this storage area, it would be immediately used for exactly one paste, and then never accessed again until the next paste action caused it to be freed and replaced with a new chunk of pasted data. So why on earth was it stored persistently at all, and why that callback mechanism from frontend to terminal back to frontend to retrieve it for the actual paste action? I have no idea. This change removes the entire system and replaces it with the completely obvious alternative: the character-set-converted version of paste data is allocated in a _local_ variable in the frontend paste functions, passed directly to term_do_paste which now takes (buffer,length) parameters, and freed immediately afterwards. get_clip() is gone.
2017-12-09 08:41:03 +00:00
term_do_paste(inst->term, paste, paste_len);
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
Stop front ends remembering the data of their last paste. Previously, both the Unix and Windows front ends would respond to a paste action by retrieving data from the system clipboard, converting it appropriately, _storing_ it in a persistent dynamic data block inside the front end, and then calling term_do_paste(term), which in turn would call back to the front end via get_clip() to retrieve the current contents of that stored data block. But, as far as I can tell, this was a completely pointless mechanism, because after a data block was written into this storage area, it would be immediately used for exactly one paste, and then never accessed again until the next paste action caused it to be freed and replaced with a new chunk of pasted data. So why on earth was it stored persistently at all, and why that callback mechanism from frontend to terminal back to frontend to retrieve it for the actual paste action? I have no idea. This change removes the entire system and replaces it with the completely obvious alternative: the character-set-converted version of paste data is allocated in a _local_ variable in the frontend paste functions, passed directly to term_do_paste which now takes (buffer,length) parameters, and freed immediately afterwards. get_clip() is gone.
2017-12-09 08:41:03 +00:00
sfree(paste);
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_clip_request_paste(TermWin *tw, int clipboard)
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state *state = &inst->clipstates[clipboard];
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
if (!state->gtkclipboard)
return;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
gtk_clipboard_request_text(state->gtkclipboard,
clipboard_text_received, inst);
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
}
#else /* JUST_USE_GTK_CLIPBOARD_UTF8 */
/* ----------------------------------------------------------------------
* Clipboard handling for X, using the low-level gtk_selection_*
* interface, handling conversions to fiddly things like compound text
* ourselves, and storing in X cut buffers too.
*
* This version of the clipboard code has to be kept around for GTK1,
* which doesn't have the higher-level GtkClipboard interface at all.
* And since it works on GTK2 and GTK3 too and has had a good few
* years of shakedown and bug fixing, we might as well keep using it
* where it's applicable.
*
* It's _possible_ that we might be able to replicate all the
* important wrinkles of this code in GtkClipboard. (In particular,
* cut buffers or local analogue look as if they might be accessible
* via gtk_clipboard_set_can_store(), and delivering text in
* non-Unicode formats only in the direct-to-font case ought to be
* possible if we can figure out the right set of things to put in the
* GtkTargetList.) But that work can wait until there's a need for it!
*/
Fix build failure at -DNOT_X_WINDOWS. I had been indecisive about whether the definitions and calls of store_cutbuffer and retrieve_cutbuffer should be compiled out completely in GTK-without-X mode, or whether the definitions should be left in as stubs and the calls still present. retrieve_cutbuffer ended up with a definition but no call in that mode. It was only an unused-function warning, but -Werror promoted it to an error. Fixed by making up my mind: now the functions are completely absent, and so are the calls to them.
2021-01-26 18:12:48 +00:00
#ifndef NOT_X_WINDOWS
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
/* Store the data in a cut-buffer. */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void store_cutbuffer(GtkFrontend *inst, char *ptr, int len)
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
{
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
if (inst->disp) {
/* ICCCM says we must rotate the buffers before storing to buffer 0. */
XRotateBuffers(inst->disp, 1);
XStoreBytes(inst->disp, ptr, len);
}
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
}
/* Retrieve data from a cut-buffer.
* Returned data needs to be freed with XFree().
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static char *retrieve_cutbuffer(GtkFrontend *inst, int *nbytes)
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
{
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
char *ptr;
if (!inst->disp) {
*nbytes = 0;
return NULL;
}
ptr = XFetchBytes(inst->disp, nbytes);
Arnaud Desitter points out a silly mistake in retrieve_cutbuffer() (don't test for `int *nbytes' being <= 0, test for the integer it points to being <= 0!). [originally from svn r4254]
2004-05-24 11:30:15 +00:00
if (*nbytes <= 0 && ptr != 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
XFree(ptr);
ptr = 0;
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
}
return ptr;
}
Fix build failure at -DNOT_X_WINDOWS. I had been indecisive about whether the definitions and calls of store_cutbuffer and retrieve_cutbuffer should be compiled out completely in GTK-without-X mode, or whether the definitions should be left in as stubs and the calls still present. retrieve_cutbuffer ended up with a definition but no call in that mode. It was only an unused-function warning, but -Werror promoted it to an error. Fixed by making up my mind: now the functions are completely absent, and so are the calls to them.
2021-01-26 18:12:48 +00:00
#endif /* NOT_X_WINDOWS */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_clip_write(
TermWin *tw, int clipboard, wchar_t *data, int *attr,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
truecolour *truecolour, int len, bool must_deselect)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state *state = &inst->clipstates[clipboard];
if (state->pasteout_data)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(state->pasteout_data);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
if (state->pasteout_data_ctext)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(state->pasteout_data_ctext);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
if (state->pasteout_data_utf8)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(state->pasteout_data_utf8);
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
Proper support for using the font's own character encoding. If we know what that encoding actually is, we can do our best to support additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using the available characters; if we don't, we fall back to a mode where we disable all Unicode cut-and-paste and assume any Unicode character is undisplayable. [originally from svn r2413]
2003-01-01 22:25:25 +00:00
/*
Real COMPOUND_TEXT support! I was expecting to have to read the spec and implement the required subset of ISO-2022 in libcharset, but it turns out that Xlib provides conversion functions between UTF-8 and compound text, which are just about ideal for us. So now we can paste multilingual stuff both to and from emacs21. Rock on. [originally from svn r3193]
2003-05-13 19:57:17 +00:00
* Set up UTF-8 and compound text paste data. This only happens
* if we aren't in direct-to-font mode using the D800 hack.
Proper support for using the font's own character encoding. If we know what that encoding actually is, we can do our best to support additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using the available characters; if we don't, we fall back to a mode where we disable all Unicode cut-and-paste and assume any Unicode character is undisplayable. [originally from svn r2413]
2003-01-01 22:25:25 +00:00
*/
Fixes to direct-to-font mode: I'd inadvertently enabled it for any font whose encoding comes up as CS_NONE - but this is also true for iso10646-1 fonts, since libcharset doesn't support wide-character encodings! Hence UTF-8 cut and paste was enabled in ordinary modes, but disabled in UTF-8 mode, which was a bit embarrassing. Now we have a dedicated flag variable indicating direct-to-font mode. [originally from svn r2425]
2003-01-02 16:17:56 +00:00
if (!inst->direct_to_font) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
const wchar_t *tmp = data;
int tmplen = len;
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#ifndef NOT_X_WINDOWS
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
XTextProperty tp;
char *list[1];
#endif
state->pasteout_data_utf8 = snewn(len*6, char);
state->pasteout_data_utf8_len = len*6;
state->pasteout_data_utf8_len =
charset_from_unicode(&tmp, &tmplen, state->pasteout_data_utf8,
state->pasteout_data_utf8_len,
CS_UTF8, NULL, NULL, 0);
if (state->pasteout_data_utf8_len == 0) {
sfree(state->pasteout_data_utf8);
state->pasteout_data_utf8 = NULL;
} else {
state->pasteout_data_utf8 =
sresize(state->pasteout_data_utf8,
state->pasteout_data_utf8_len + 1, char);
state->pasteout_data_utf8[state->pasteout_data_utf8_len] = '\0';
}
/*
* Now let Xlib convert our UTF-8 data into compound text.
*/
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#ifndef NOT_X_WINDOWS
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
list[0] = state->pasteout_data_utf8;
if (inst->disp && Xutf8TextListToTextProperty(
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
inst->disp, list, 1, XCompoundTextStyle, &tp) == 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
state->pasteout_data_ctext = snewn(tp.nitems+1, char);
memcpy(state->pasteout_data_ctext, tp.value, tp.nitems);
state->pasteout_data_ctext_len = tp.nitems;
XFree(tp.value);
} else
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#endif
{
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
state->pasteout_data_ctext = NULL;
state->pasteout_data_ctext_len = 0;
Fix double-free in X selection code. [originally from svn r4367]
2004-07-27 15:20:37 +00:00
}
Proper support for using the font's own character encoding. If we know what that encoding actually is, we can do our best to support additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using the available characters; if we don't, we fall back to a mode where we disable all Unicode cut-and-paste and assume any Unicode character is undisplayable. [originally from svn r2413]
2003-01-01 22:25:25 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
state->pasteout_data_utf8 = NULL;
state->pasteout_data_utf8_len = 0;
state->pasteout_data_ctext = NULL;
state->pasteout_data_ctext_len = 0;
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
}
Rework Unicode conversion APIs to use a BinarySink. The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs. This commit introduces a fresh pair of functions to replace them, which generate output by writing to a BinarySink. So it's now up to the caller to decide whether it wants the output written to a fixed-size buffer with overflow checking (via buffer_sink), or dynamically allocated, or even written directly to some other output channel. Nothing uses the new functions yet. I plan to migrate things over in upcoming commits. What was wrong with the old APIs: they had that awkward undocumented Windows-specific 'flags' parameter that I described in the previous commit and took out of the dup_X_to_Y wrappers. But much worse, the semantics for buffer overflow were not just undocumented but actually inconsistent. dup_wc_to_mb() in utils assumed that the underlying wc_to_mb would fill the buffer nearly full and return the size of data it wrote. In fact, this was untrue in the case where wc_to_mb called WideCharToMultiByte: that returns straight-up failure, setting the Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially fill the output buffer, but doesn't tell you how much it wrote! What's wrong with the new API: it's a bit awkward to write a sequence of wchar_t in native byte order to a byte-oriented BinarySink, so people using put_mb_to_wc directly have to do some annoying pointer casting. But I think that's less horrible than the previous APIs. Another change: in the new API for wc_to_mb, defchr can be "", but not NULL.
2024-09-24 07:18:48 +00:00
{
size_t outlen;
state->pasteout_data = dup_wc_to_mb_c(
inst->ucsdata.line_codepage, data, len, "", &outlen);
/* We can't handle pastes larger than INT_MAX, because
* gtk_selection_data_set_text's length parameter is a gint */
if (outlen > INT_MAX)
outlen = INT_MAX;
state->pasteout_data_len = outlen;
Fixes to direct-to-font mode: I'd inadvertently enabled it for any font whose encoding comes up as CS_NONE - but this is also true for iso10646-1 fonts, since libcharset doesn't support wide-character encodings! Hence UTF-8 cut and paste was enabled in ordinary modes, but disabled in UTF-8 mode, which was a bit embarrassing. Now we have a dedicated flag variable indicating direct-to-font mode. [originally from svn r2425]
2003-01-02 16:17:56 +00:00
}
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
Fix build failure at -DNOT_X_WINDOWS. I had been indecisive about whether the definitions and calls of store_cutbuffer and retrieve_cutbuffer should be compiled out completely in GTK-without-X mode, or whether the definitions should be left in as stubs and the calls still present. retrieve_cutbuffer ended up with a definition but no call in that mode. It was only an unused-function warning, but -Werror promoted it to an error. Fixed by making up my mind: now the functions are completely absent, and so are the calls to them.
2021-01-26 18:12:48 +00:00
#ifndef NOT_X_WINDOWS
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
/* The legacy X cut buffers go with PRIMARY, not any other clipboard */
if (state->atom == GDK_SELECTION_PRIMARY)
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
store_cutbuffer(inst, state->pasteout_data, state->pasteout_data_len);
Fix build failure at -DNOT_X_WINDOWS. I had been indecisive about whether the definitions and calls of store_cutbuffer and retrieve_cutbuffer should be compiled out completely in GTK-without-X mode, or whether the definitions should be left in as stubs and the calls still present. retrieve_cutbuffer ended up with a definition but no call in that mode. It was only an unused-function warning, but -Werror promoted it to an error. Fixed by making up my mind: now the functions are completely absent, and so are the calls to them.
2021-01-26 18:12:48 +00:00
#endif
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
if (gtk_selection_owner_set(inst->area, state->atom,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->input_event_time)) {
gtk_selection_clear_targets() does not exist on GTK 1, so ifdef it. [originally from svn r8371]
2008-12-03 00:06:38 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_selection_clear_targets(inst->area, state->atom);
gtk_selection_clear_targets() does not exist on GTK 1, so ifdef it. [originally from svn r8371]
2008-12-03 00:06:38 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_selection_add_target(inst->area, state->atom,
GDK_SELECTION_TYPE_STRING, 1);
if (state->pasteout_data_ctext)
gtk_selection_add_target(inst->area, state->atom,
compound_text_atom, 1);
if (state->pasteout_data_utf8)
gtk_selection_add_target(inst->area, state->atom,
utf8_string_atom, 1);
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
`Copy All' ought to de-highlight any existing selection, in line with any other operation that shifts the X selection to stuff other than the highlighted text. [originally from svn r3098]
2003-04-11 18:10:13 +00:00
if (must_deselect)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_lost_clipboard_ownership(inst->term, clipboard);
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
static void selection_get(GtkWidget *widget, GtkSelectionData *seldata,
guint info, guint time_stamp, gpointer data)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
GdkAtom target = gtk_selection_data_get_target(seldata);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state *state = clipboard_from_atom(
inst, gtk_selection_data_get_selection(seldata));
if (!state)
return;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (target == utf8_string_atom)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_selection_data_set(seldata, target, 8,
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
(unsigned char *)state->pasteout_data_utf8,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
state->pasteout_data_utf8_len);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
else if (target == compound_text_atom)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_selection_data_set(seldata, target, 8,
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
(unsigned char *)state->pasteout_data_ctext,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
state->pasteout_data_ctext_len);
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_selection_data_set(seldata, target, 8,
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
(unsigned char *)state->pasteout_data,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
state->pasteout_data_len);
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
static gint selection_clear(GtkWidget *widget, GdkEventSelection *seldata,
gpointer data)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state *state = clipboard_from_atom(
inst, seldata->selection);
Richard Boulton's patch for improved correctness in selection handling (generally, selection request timestamps should be set to the timestamp on the event that caused them). [originally from svn r3408]
2003-08-21 18:03:06 +00:00
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
if (!state)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
term_lost_clipboard_ownership(inst->term, state->clipboard);
if (state->pasteout_data)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(state->pasteout_data);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
if (state->pasteout_data_ctext)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(state->pasteout_data_ctext);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
if (state->pasteout_data_utf8)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(state->pasteout_data_utf8);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
state->pasteout_data = NULL;
state->pasteout_data_len = 0;
state->pasteout_data_ctext = NULL;
state->pasteout_data_ctext_len = 0;
state->pasteout_data_utf8 = NULL;
state->pasteout_data_utf8_len = 0;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_clip_request_paste(TermWin *tw, int clipboard)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state *state = &inst->clipstates[clipboard];
Add a system of clipboard identifiers. This lays some groundwork for making PuTTY's cut and paste handling more flexible in the area of which clipboard(s) it reads and writes, if more than one is available on the system. I've introduced a system of list macros which define an enumeration of integer clipboard ids, some defined centrally in putty.h (at present just a CLIP_NULL which never has any text in it, because that seems like the sort of thing that will come in useful for configuring a given copy or paste UI action to be ignored) and some defined per platform. All the front end functions that copy and paste take a clipboard id, and the Terminal structure is now configured at startup to tell it which clipboard id it should paste from on a mouse click, and which it should copy from on a selection. However, I haven't actually added _real_ support for multiple X11 clipboards, in that the Unix front end supports a single CLIP_SYSTEM regardless of whether it's in OS X or GTK mode. So this is currently a NFC refactoring which does nothing but prepare the way for real changes to come.
2017-12-09 12:00:13 +00:00
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
/*
* In Unix, pasting is asynchronous: all we can do at the
* moment is to call gtk_selection_convert(), and when the data
* comes back _then_ we can call term_do_paste().
*/
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
Fixes to direct-to-font mode: I'd inadvertently enabled it for any font whose encoding comes up as CS_NONE - but this is also true for iso10646-1 fonts, since libcharset doesn't support wide-character encodings! Hence UTF-8 cut and paste was enabled in ordinary modes, but disabled in UTF-8 mode, which was a bit embarrassing. Now we have a dedicated flag variable indicating direct-to-font mode. [originally from svn r2425]
2003-01-02 16:17:56 +00:00
if (!inst->direct_to_font) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* First we attempt to retrieve the selection as a UTF-8
* string (which we will convert to the correct code page
* before sending to the session, of course). If that
* fails, selection_received() will be informed and will
* fall back to an ordinary string.
*/
gtk_selection_convert(inst->area, state->atom, utf8_string_atom,
inst->input_event_time);
Proper support for using the font's own character encoding. If we know what that encoding actually is, we can do our best to support additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using the available characters; if we don't, we fall back to a mode where we disable all Unicode cut-and-paste and assume any Unicode character is undisplayable. [originally from svn r2413]
2003-01-01 22:25:25 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* If we're in direct-to-font mode, we disable UTF-8
* pasting, and go straight to ordinary string data.
*/
gtk_selection_convert(inst->area, state->atom,
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
GDK_SELECTION_TYPE_STRING,
inst->input_event_time);
Proper support for using the font's own character encoding. If we know what that encoding actually is, we can do our best to support additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using the available characters; if we don't, we fall back to a mode where we disable all Unicode cut-and-paste and assume any Unicode character is undisplayable. [originally from svn r2413]
2003-01-01 22:25:25 +00:00
}
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
}
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
static void selection_received(GtkWidget *widget, GtkSelectionData *seldata,
guint time, gpointer data)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Real COMPOUND_TEXT support! I was expecting to have to read the spec and implement the required subset of ISO-2022 in libcharset, but it turns out that Xlib provides conversion functions between UTF-8 and compound text, which are just about ideal for us. So now we can paste multilingual stuff both to and from emacs21. Rock on. [originally from svn r3193]
2003-05-13 19:57:17 +00:00
char *text;
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
int length;
#ifndef NOT_X_WINDOWS
char **list;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool free_list_required = false;
bool free_required = false;
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#endif
Real COMPOUND_TEXT support! I was expecting to have to read the spec and implement the required subset of ISO-2022 in libcharset, but it turns out that Xlib provides conversion functions between UTF-8 and compound text, which are just about ideal for us. So now we can paste multilingual stuff both to and from emacs21. Rock on. [originally from svn r3193]
2003-05-13 19:57:17 +00:00
int charset;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
GdkAtom seldata_target = gtk_selection_data_get_target(seldata);
GdkAtom seldata_type = gtk_selection_data_get_data_type(seldata);
const guchar *seldata_data = gtk_selection_data_get_data(seldata);
gint seldata_length = gtk_selection_data_get_length(seldata);
Stop front ends remembering the data of their last paste. Previously, both the Unix and Windows front ends would respond to a paste action by retrieving data from the system clipboard, converting it appropriately, _storing_ it in a persistent dynamic data block inside the front end, and then calling term_do_paste(term), which in turn would call back to the front end via get_clip() to retrieve the current contents of that stored data block. But, as far as I can tell, this was a completely pointless mechanism, because after a data block was written into this storage area, it would be immediately used for exactly one paste, and then never accessed again until the next paste action caused it to be freed and replaced with a new chunk of pasted data. So why on earth was it stored persistently at all, and why that callback mechanism from frontend to terminal back to frontend to retrieve it for the actual paste action? I have no idea. This change removes the entire system and replaces it with the completely obvious alternative: the character-set-converted version of paste data is allocated in a _local_ variable in the frontend paste functions, passed directly to term_do_paste which now takes (buffer,length) parameters, and freed immediately afterwards. get_clip() is gone.
2017-12-09 08:41:03 +00:00
wchar_t *paste;
Rework Unicode conversion APIs to use a BinarySink. The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs. This commit introduces a fresh pair of functions to replace them, which generate output by writing to a BinarySink. So it's now up to the caller to decide whether it wants the output written to a fixed-size buffer with overflow checking (via buffer_sink), or dynamically allocated, or even written directly to some other output channel. Nothing uses the new functions yet. I plan to migrate things over in upcoming commits. What was wrong with the old APIs: they had that awkward undocumented Windows-specific 'flags' parameter that I described in the previous commit and took out of the dup_X_to_Y wrappers. But much worse, the semantics for buffer overflow were not just undocumented but actually inconsistent. dup_wc_to_mb() in utils assumed that the underlying wc_to_mb would fill the buffer nearly full and return the size of data it wrote. In fact, this was untrue in the case where wc_to_mb called WideCharToMultiByte: that returns straight-up failure, setting the Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially fill the output buffer, but doesn't tell you how much it wrote! What's wrong with the new API: it's a bit awkward to write a sequence of wchar_t in native byte order to a byte-oriented BinarySink, so people using put_mb_to_wc directly have to do some annoying pointer casting. But I think that's less horrible than the previous APIs. Another change: in the new API for wc_to_mb, defchr can be "", but not NULL.
2024-09-24 07:18:48 +00:00
size_t paste_len;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
struct clipboard_state *state = clipboard_from_atom(
inst, gtk_selection_data_get_selection(seldata));
if (!state)
return;
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (seldata_target == utf8_string_atom && seldata_length <= 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Failed to get a UTF-8 selection string. Try compound
* text next.
*/
gtk_selection_convert(inst->area, state->atom,
compound_text_atom,
inst->input_event_time);
return;
Allow pterm to receive selections in compound text format. Doesn't actually _understand_ compound text yet - anything with non-ASCII-or-8859-1 characters will fail miserably - but it will at least successfully receive plain text if the pasting application doesn't see fit to give it out in any other format. [originally from svn r3192]
2003-05-13 18:43:30 +00:00
}
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (seldata_target == compound_text_atom && seldata_length <= 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Failed to get UTF-8 or compound text. Try an ordinary
* string.
*/
gtk_selection_convert(inst->area, state->atom,
GDK_SELECTION_TYPE_STRING,
inst->input_event_time);
return;
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
}
/*
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
* If we have data, but it's not of a type we can deal with,
* we have to ignore the data.
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
*/
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (seldata_length > 0 &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
seldata_type != GDK_SELECTION_TYPE_STRING &&
seldata_type != compound_text_atom &&
seldata_type != utf8_string_atom)
return;
Real COMPOUND_TEXT support! I was expecting to have to read the spec and implement the required subset of ISO-2022 in libcharset, but it turns out that Xlib provides conversion functions between UTF-8 and compound text, which are just about ideal for us. So now we can paste multilingual stuff both to and from emacs21. Rock on. [originally from svn r3193]
2003-05-13 19:57:17 +00:00
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
/*
* If we have no data, try looking in a cut buffer.
*/
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (seldata_length <= 0) {
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#ifndef NOT_X_WINDOWS
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
text = retrieve_cutbuffer(inst, &length);
if (length == 0)
return;
Fix a batch of typos in comments and docs.
2022-01-03 06:38:07 +00:00
/* Xterm is rumoured to expect Latin-1, though I haven't checked the
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
* source, so use that as a de-facto standard. */
charset = CS_ISO8859_1;
free_required = true;
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#else
return;
#endif
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Convert COMPOUND_TEXT into UTF-8.
*/
if (seldata_type == compound_text_atom) {
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#ifndef NOT_X_WINDOWS
XTextProperty tp;
int ret, count;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
tp.value = (unsigned char *)seldata_data;
tp.encoding = (Atom) seldata_type;
tp.format = gtk_selection_data_get_format(seldata);
tp.nitems = seldata_length;
ret = inst->disp == NULL ? -1 :
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
Xutf8TextPropertyToTextList(inst->disp, &tp, &list, &count);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ret == 0 && count == 1) {
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
text = list[0];
length = strlen(list[0]);
charset = CS_UTF8;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
free_list_required = true;
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
} else
#endif
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Compound text failed; fall back to STRING.
*/
gtk_selection_convert(inst->area, state->atom,
GDK_SELECTION_TYPE_STRING,
inst->input_event_time);
return;
}
} else {
text = (char *)seldata_data;
length = seldata_length;
charset = (seldata_type == utf8_string_atom ?
CS_UTF8 : inst->ucsdata.line_codepage);
}
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
}
Real COMPOUND_TEXT support! I was expecting to have to read the spec and implement the required subset of ISO-2022 in libcharset, but it turns out that Xlib provides conversion functions between UTF-8 and compound text, which are just about ideal for us. So now we can paste multilingual stuff both to and from emacs21. Rock on. [originally from svn r3193]
2003-05-13 19:57:17 +00:00
Rework Unicode conversion APIs to use a BinarySink. The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs. This commit introduces a fresh pair of functions to replace them, which generate output by writing to a BinarySink. So it's now up to the caller to decide whether it wants the output written to a fixed-size buffer with overflow checking (via buffer_sink), or dynamically allocated, or even written directly to some other output channel. Nothing uses the new functions yet. I plan to migrate things over in upcoming commits. What was wrong with the old APIs: they had that awkward undocumented Windows-specific 'flags' parameter that I described in the previous commit and took out of the dup_X_to_Y wrappers. But much worse, the semantics for buffer overflow were not just undocumented but actually inconsistent. dup_wc_to_mb() in utils assumed that the underlying wc_to_mb would fill the buffer nearly full and return the size of data it wrote. In fact, this was untrue in the case where wc_to_mb called WideCharToMultiByte: that returns straight-up failure, setting the Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially fill the output buffer, but doesn't tell you how much it wrote! What's wrong with the new API: it's a bit awkward to write a sequence of wchar_t in native byte order to a byte-oriented BinarySink, so people using put_mb_to_wc directly have to do some annoying pointer casting. But I think that's less horrible than the previous APIs. Another change: in the new API for wc_to_mb, defchr can be "", but not NULL.
2024-09-24 07:18:48 +00:00
paste = dup_mb_to_wc_c(charset, text, length, &paste_len);
Stop front ends remembering the data of their last paste. Previously, both the Unix and Windows front ends would respond to a paste action by retrieving data from the system clipboard, converting it appropriately, _storing_ it in a persistent dynamic data block inside the front end, and then calling term_do_paste(term), which in turn would call back to the front end via get_clip() to retrieve the current contents of that stored data block. But, as far as I can tell, this was a completely pointless mechanism, because after a data block was written into this storage area, it would be immediately used for exactly one paste, and then never accessed again until the next paste action caused it to be freed and replaced with a new chunk of pasted data. So why on earth was it stored persistently at all, and why that callback mechanism from frontend to terminal back to frontend to retrieve it for the actual paste action? I have no idea. This change removes the entire system and replaces it with the completely obvious alternative: the character-set-converted version of paste data is allocated in a _local_ variable in the frontend paste functions, passed directly to term_do_paste which now takes (buffer,length) parameters, and freed immediately afterwards. get_clip() is gone.
2017-12-09 08:41:03 +00:00
term_do_paste(inst->term, paste, paste_len);
sfree(paste);
Only engage a GTK idle function when absolutely necessary, otherwise the whole app spins on it and takes up CPU all the time. [originally from svn r2052]
2002-10-14 23:32:00 +00:00
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#ifndef NOT_X_WINDOWS
Real COMPOUND_TEXT support! I was expecting to have to read the spec and implement the required subset of ISO-2022 in libcharset, but it turns out that Xlib provides conversion functions between UTF-8 and compound text, which are just about ideal for us. So now we can paste multilingual stuff both to and from emacs21. Rock on. [originally from svn r3193]
2003-05-13 19:57:17 +00:00
if (free_list_required)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
XFreeStringList(list);
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 18:07:27 +00:00
if (free_required)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
XFree(text);
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#endif
Only engage a GTK idle function when absolutely necessary, otherwise the whole app spins on it and takes up CPU all the time. [originally from svn r2052]
2002-10-14 23:32:00 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void init_one_clipboard(GtkFrontend *inst, int clipboard)
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
{
struct clipboard_state *state = &inst->clipstates[clipboard];
state->inst = inst;
state->clipboard = clipboard;
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void set_clipboard_atom(GtkFrontend *inst, int clipboard, GdkAtom atom)
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
{
struct clipboard_state *state = &inst->clipstates[clipboard];
state->inst = inst;
state->clipboard = clipboard;
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
state->atom = atom;
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void init_clipboard(GtkFrontend *inst)
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
{
#ifndef NOT_X_WINDOWS
/*
* Ensure that all the cut buffers exist - according to the ICCCM,
* we must do this before we start using cut buffers.
*/
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
if (inst->disp) {
unsigned char empty[] = "";
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER0,
XA_STRING, 8, PropModeAppend, empty, 0);
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER1,
XA_STRING, 8, PropModeAppend, empty, 0);
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER2,
XA_STRING, 8, PropModeAppend, empty, 0);
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER3,
XA_STRING, 8, PropModeAppend, empty, 0);
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER4,
XA_STRING, 8, PropModeAppend, empty, 0);
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER5,
XA_STRING, 8, PropModeAppend, empty, 0);
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER6,
XA_STRING, 8, PropModeAppend, empty, 0);
x11_ignore_error(inst->disp, BadMatch);
XChangeProperty(inst->disp, GDK_ROOT_WINDOW(), XA_CUT_BUFFER7,
XA_STRING, 8, PropModeAppend, empty, 0);
}
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
#endif
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
inst->clipstates[CLIP_PRIMARY].atom = GDK_SELECTION_PRIMARY;
GTK1 build fixes. Looks as if I haven't retried the GTK1 build for a while, and recent GTK frontend development has broken it. The selection revamp has pointed out that GTK1 didn't have the accessor function gtk_selection_data_get_selection(), the standard GdkAtom value GDK_SELECTION_CLIPBOARD, or keysyms for alphabetic characters; and also I had an initialisation of one of my own structure fields (dp->selparams) accidentally not guarded by the same GTK-versioning ifdef that controls whether or not it was defined.
2018-03-03 18:18:54 +00:00
inst->clipstates[CLIP_CLIPBOARD].atom = clipboard_atom;
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
init_one_clipboard(inst, CLIP_PRIMARY);
init_one_clipboard(inst, CLIP_CLIPBOARD);
Make gtkwin.c able to support multiple selections. All the data fields referring to the selection in 'struct gui_data' have been pulled out into a separate structure of which there are now multiple instances, and I've plumbed through what should be the right pointers and integer ids to everywhere they should go. So now the GTK front end defines CLIP_PRIMARY and CLIP_CLIPBOARD in place of the temporary cop-out CLIP_SYSTEM from the previous commit, and copying and pasting can be done via either one. The defaults should be the same as before, except that now the non-Mac versions of the GtkApplication front ends will access CLIP_PRIMARY in response to most actions but the 'Paste' menu item will paste from CLIP_CLIPBOARD. (That's mostly just as a demonstration that accessing multiple clipboards even works.)
2017-12-10 10:23:39 +00:00
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
g_signal_connect(G_OBJECT(inst->area), "selection_received",
G_CALLBACK(selection_received), inst);
g_signal_connect(G_OBJECT(inst->area), "selection_get",
G_CALLBACK(selection_get), inst);
g_signal_connect(G_OBJECT(inst->area), "selection_clear_event",
G_CALLBACK(selection_clear), inst);
}
/*
* End of selection/clipboard handling.
* ----------------------------------------------------------------------
*/
#endif /* JUST_USE_GTK_CLIPBOARD_UTF8 */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void set_window_titles(GtkFrontend *inst)
Aha, _that's_ why the icon title didn't work properly in pterm: gtk_window_set_title() overwrote both titles at once. Icon title is now working properly under X, and since X was the reason for the whole icon/window title separation _anyway_ they default to being separate. [originally from svn r3144]
2003-04-26 13:55:47 +00:00
{
/*
* We must always call set_icon_name after calling set_title,
* since set_title will write both names. Irritating, but such
* is life.
*/
gtk_window_set_title(GTK_WINDOW(inst->window), inst->wintitle);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(inst->conf, CONF_win_name_always))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gdk_window_set_icon_name(gtk_widget_get_window(inst->window),
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
inst->icontitle);
Aha, _that's_ why the icon title didn't work properly in pterm: gtk_window_set_title() overwrote both titles at once. Icon title is now working properly under X, and since X was the reason for the whole icon/window title separation _anyway_ they default to being separate. [originally from svn r3144]
2003-04-26 13:55:47 +00:00
}
win_set_[icon_]title: send a codepage along with the string. While fixing the previous commit I noticed that window titles don't actually _work_ properly if you change the terminal character set, because the text accumulated in the OSC string buffer is sent to the TermWin as raw bytes, with no indication of what character set it should interpret them as. You might get lucky if you happened to choose the right charset (in particular, UTF-8 is a common default), but if you change the charset half way through a run, then there's certainly no way the frontend will know to interpret two window titles sent before and after the change in two different charsets. So, now win_set_title() and win_set_icon_title() both include a codepage parameter along with the byte string, and it's up to them to translate the provided window title from that encoding to whatever the local window system expects to receive. On Windows, that's wide-string Unicode, so we can just use the existing dup_mb_to_wc utility function. But in GTK, it's UTF-8, so I had to write an extra utility function to encode a wide string as UTF-8.
2021-10-16 12:20:44 +00:00
static void gtkwin_set_title(TermWin *tw, const char *title, int codepage)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
sfree(inst->wintitle);
win_set_[icon_]title: send a codepage along with the string. While fixing the previous commit I noticed that window titles don't actually _work_ properly if you change the terminal character set, because the text accumulated in the OSC string buffer is sent to the TermWin as raw bytes, with no indication of what character set it should interpret them as. You might get lucky if you happened to choose the right charset (in particular, UTF-8 is a common default), but if you change the charset half way through a run, then there's certainly no way the frontend will know to interpret two window titles sent before and after the change in two different charsets. So, now win_set_title() and win_set_icon_title() both include a codepage parameter along with the byte string, and it's up to them to translate the provided window title from that encoding to whatever the local window system expects to receive. On Windows, that's wide-string Unicode, so we can just use the existing dup_mb_to_wc utility function. But in GTK, it's UTF-8, so I had to write an extra utility function to encode a wide string as UTF-8.
2021-10-16 12:20:44 +00:00
if (codepage != CP_UTF8) {
dup_mb_to_wc, dup_wc_to_mb: remove the 'flags' parameter. This parameter was undocumented, and Windows-specific: its semantics date from before PuTTY was cross-platform, and are "Pass this flags parameter straight through to the Win32 API's conversion functions". So in Windows platform code you can pass flags like MB_USEGLYPHCHARS, but in cross-platform code, you dare not pass anything nonzero at all because the Unix frontend won't recognise it (or, likely, even compile). I've kept the flag for now in the underlying mb_to_wc / wc_to_mb functions. Partly that's because there's one place in the Windows code where the parameter _is_ used; mostly, it's because I'm about to replace those functions anyway, so there's no point in editing all the call sites twice.
2024-09-24 07:46:39 +00:00
wchar_t *title_w = dup_mb_to_wc(codepage, title);
win_set_[icon_]title: send a codepage along with the string. While fixing the previous commit I noticed that window titles don't actually _work_ properly if you change the terminal character set, because the text accumulated in the OSC string buffer is sent to the TermWin as raw bytes, with no indication of what character set it should interpret them as. You might get lucky if you happened to choose the right charset (in particular, UTF-8 is a common default), but if you change the charset half way through a run, then there's certainly no way the frontend will know to interpret two window titles sent before and after the change in two different charsets. So, now win_set_title() and win_set_icon_title() both include a codepage parameter along with the byte string, and it's up to them to translate the provided window title from that encoding to whatever the local window system expects to receive. On Windows, that's wide-string Unicode, so we can just use the existing dup_mb_to_wc utility function. But in GTK, it's UTF-8, so I had to write an extra utility function to encode a wide string as UTF-8.
2021-10-16 12:20:44 +00:00
inst->wintitle = encode_wide_string_as_utf8(title_w);
sfree(title_w);
} else {
inst->wintitle = dupstr(title);
}
Aha, _that's_ why the icon title didn't work properly in pterm: gtk_window_set_title() overwrote both titles at once. Icon title is now working properly under X, and since X was the reason for the whole icon/window title separation _anyway_ they default to being separate. [originally from svn r3144]
2003-04-26 13:55:47 +00:00
set_window_titles(inst);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
win_set_[icon_]title: send a codepage along with the string. While fixing the previous commit I noticed that window titles don't actually _work_ properly if you change the terminal character set, because the text accumulated in the OSC string buffer is sent to the TermWin as raw bytes, with no indication of what character set it should interpret them as. You might get lucky if you happened to choose the right charset (in particular, UTF-8 is a common default), but if you change the charset half way through a run, then there's certainly no way the frontend will know to interpret two window titles sent before and after the change in two different charsets. So, now win_set_title() and win_set_icon_title() both include a codepage parameter along with the byte string, and it's up to them to translate the provided window title from that encoding to whatever the local window system expects to receive. On Windows, that's wide-string Unicode, so we can just use the existing dup_mb_to_wc utility function. But in GTK, it's UTF-8, so I had to write an extra utility function to encode a wide string as UTF-8.
2021-10-16 12:20:44 +00:00
static void gtkwin_set_icon_title(TermWin *tw, const char *title, int codepage)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
sfree(inst->icontitle);
win_set_[icon_]title: send a codepage along with the string. While fixing the previous commit I noticed that window titles don't actually _work_ properly if you change the terminal character set, because the text accumulated in the OSC string buffer is sent to the TermWin as raw bytes, with no indication of what character set it should interpret them as. You might get lucky if you happened to choose the right charset (in particular, UTF-8 is a common default), but if you change the charset half way through a run, then there's certainly no way the frontend will know to interpret two window titles sent before and after the change in two different charsets. So, now win_set_title() and win_set_icon_title() both include a codepage parameter along with the byte string, and it's up to them to translate the provided window title from that encoding to whatever the local window system expects to receive. On Windows, that's wide-string Unicode, so we can just use the existing dup_mb_to_wc utility function. But in GTK, it's UTF-8, so I had to write an extra utility function to encode a wide string as UTF-8.
2021-10-16 12:20:44 +00:00
if (codepage != CP_UTF8) {
dup_mb_to_wc, dup_wc_to_mb: remove the 'flags' parameter. This parameter was undocumented, and Windows-specific: its semantics date from before PuTTY was cross-platform, and are "Pass this flags parameter straight through to the Win32 API's conversion functions". So in Windows platform code you can pass flags like MB_USEGLYPHCHARS, but in cross-platform code, you dare not pass anything nonzero at all because the Unix frontend won't recognise it (or, likely, even compile). I've kept the flag for now in the underlying mb_to_wc / wc_to_mb functions. Partly that's because there's one place in the Windows code where the parameter _is_ used; mostly, it's because I'm about to replace those functions anyway, so there's no point in editing all the call sites twice.
2024-09-24 07:46:39 +00:00
wchar_t *title_w = dup_mb_to_wc(codepage, title);
win_set_[icon_]title: send a codepage along with the string. While fixing the previous commit I noticed that window titles don't actually _work_ properly if you change the terminal character set, because the text accumulated in the OSC string buffer is sent to the TermWin as raw bytes, with no indication of what character set it should interpret them as. You might get lucky if you happened to choose the right charset (in particular, UTF-8 is a common default), but if you change the charset half way through a run, then there's certainly no way the frontend will know to interpret two window titles sent before and after the change in two different charsets. So, now win_set_title() and win_set_icon_title() both include a codepage parameter along with the byte string, and it's up to them to translate the provided window title from that encoding to whatever the local window system expects to receive. On Windows, that's wide-string Unicode, so we can just use the existing dup_mb_to_wc utility function. But in GTK, it's UTF-8, so I had to write an extra utility function to encode a wide string as UTF-8.
2021-10-16 12:20:44 +00:00
inst->icontitle = encode_wide_string_as_utf8(title_w);
sfree(title_w);
} else {
inst->icontitle = dupstr(title);
}
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
set_window_titles(inst);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_set_scrollbar(TermWin *tw, int total, int start, int page)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(inst->conf, CONF_scrollbar))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->ignore_sbar = true;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
gtk_adjustment_set_lower(inst->sbar_adjust, 0);
gtk_adjustment_set_upper(inst->sbar_adjust, total);
gtk_adjustment_set_value(inst->sbar_adjust, start);
gtk_adjustment_set_page_size(inst->sbar_adjust, page);
gtk_adjustment_set_step_increment(inst->sbar_adjust, 1);
gtk_adjustment_set_page_increment(inst->sbar_adjust, page/2);
Compile fix for GTK 3.18: avoid gtk_adjustment_changed(). 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.
2016-04-03 09:10:40 +00:00
#if !GTK_CHECK_VERSION(3,18,0)
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
gtk_adjustment_changed(inst->sbar_adjust);
Compile fix for GTK 3.18: avoid gtk_adjustment_changed(). 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.
2016-04-03 09:10:40 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->ignore_sbar = false;
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void scrollbar_moved(GtkAdjustment *adj, GtkFrontend *inst)
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
{
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(inst->conf, CONF_scrollbar))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 12:44:01 +00:00
if (!inst->ignore_sbar)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_scroll(inst->term, 1, (int)gtk_adjustment_get_value(adj));
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void show_scrollbar(GtkFrontend *inst, gboolean visible)
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
{
inst->sbar_visible = visible;
if (visible)
gtk_widget_show(inst->sbar);
else
gtk_widget_hide(inst->sbar);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_set_cursor_pos(TermWin *tw, int x, int y)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
/*
* This is meaningless under X.
*/
}
terminal.c should call the frontend beep() routine even with 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]
2002-10-28 21:58:07 +00:00
/*
* This is still called when mode==BELL_VISUAL, even though the
* visual bell is handled entirely within terminal.c, because we
* may want to perform additional actions on any kind of bell (for
* example, taskbar flashing in Windows).
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_bell(TermWin *tw, int mode)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
/* GtkFrontend *inst = container_of(tw, GtkFrontend, termwin); */
Gareth pointed out yesterday that the Unix terminal front end treats BELL_DISABLED as BELL_DEFAULT. How embarrassing. [originally from svn r7316]
2007-02-24 13:36:11 +00:00
if (mode == BELL_DEFAULT)
Use gdk_display_beep() in place of obsolete gdk_beep(). Except in GTK1 (which doesn't have the former), via a gtkcompat.h workaround. Up-to-date GTK3 has deprecated gdk_beep(), causing build failures due to the default -Werror setting.
2018-03-03 18:20:04 +00:00
gdk_display_beep(gdk_display_get_default());
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static int gtkwin_char_width(TermWin *tw, int uc)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
/*
Remove a couple of outdated FIXME comments. 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.
2015-09-26 11:59:26 +00:00
* In this front end, double-width characters are handled using a
* separate font, so this can safely just return 1 always.
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
*/
return 1;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool gtkwin_setup_draw_ctx(TermWin *tw)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (!gtk_widget_get_window(inst->area))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst->uctx.type = inst->drawtype;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
/* If we're doing GDK-based drawing, then we also expect
* inst->pixmap to exist. */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst->uctx.u.gdk.target = inst->pixmap;
inst->uctx.u.gdk.gc = gdk_gc_new(gtk_widget_get_window(inst->area));
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
inst->uctx.u.cairo.widget = GTK_WIDGET(inst->area);
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
/* If we're doing Cairo drawing, we expect inst->surface to
* exist, and we draw to that first, regardless of whether we
* subsequently copy the results to inst->pixmap. */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst->uctx.u.cairo.cr = cairo_create(inst->surface);
cairo_scale(inst->uctx.u.cairo.cr, inst->scale, inst->scale);
cairo_setup_draw_ctx(inst);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_free_draw_ctx(TermWin *tw)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
gdk_gc_unref(inst->uctx.u.gdk.gc);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_destroy(inst->uctx.u.cairo.cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_update(GtkFrontend *inst, int x, int y, int w, int h)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
#if defined DRAW_TEXT_CAIRO && !defined NO_BACKING_PIXMAPS
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
/*
* If inst->surface and inst->pixmap both exist, then we've
* just drawn new content to the former which we must copy to
* the latter.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
cairo_t *cr = gdk_cairo_create(inst->pixmap);
cairo_set_source_surface(cr, inst->surface, 0, 0);
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
cairo_rectangle(cr, x, y, w, h);
cairo_fill(cr);
cairo_destroy(cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
Use a Cairo image surface as a client-side cache. 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...)
2015-09-24 13:08:25 +00:00
/*
* Now we just queue a window redraw, which will cause
* inst->surface or inst->pixmap (whichever is appropriate for our
* compile mode) to be copied to the real window when we receive
* the resulting "expose" or "draw" event.
*
* Amazingly, this one API call is actually valid in all versions
* of GTK :-)
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
gtk_widget_queue_draw_area(inst->area, x, y, w, h);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
#ifdef DRAW_TEXT_CAIRO
static void cairo_set_source_rgb_dim(cairo_t *cr, double r, double g, double b,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool dim)
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
{
if (dim)
cairo_set_source_rgb(cr, r * 2 / 3, g * 2 / 3, b * 2 / 3);
else
cairo_set_source_rgb(cr, r, g, b);
}
#endif
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void draw_set_colour(GtkFrontend *inst, int col, bool dim)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
if (dim) {
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
GdkColor color;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
color.red = inst->cols[col].red * 2 / 3;
color.green = inst->cols[col].green * 2 / 3;
color.blue = inst->cols[col].blue * 2 / 3;
gdk_gc_set_rgb_fg_color(inst->uctx.u.gdk.gc, &color);
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#else
/* Poor GTK1 fallback */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
gdk_gc_set_foreground(inst->uctx.u.gdk.gc, &inst->cols[col]);
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#endif
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
} else {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
gdk_gc_set_foreground(inst->uctx.u.gdk.gc, &inst->cols[col]);
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
}
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_set_source_rgb_dim(inst->uctx.u.cairo.cr,
inst->cols[col].red / 65535.0,
inst->cols[col].green / 65535.0,
inst->cols[col].blue / 65535.0, dim);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void draw_set_colour_rgb(GtkFrontend *inst, optionalrgb orgb, bool dim)
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
{
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GdkColor color;
color.red = orgb.r * 256;
color.green = orgb.g * 256;
color.blue = orgb.b * 256;
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
if (dim) {
color.red = color.red * 2 / 3;
color.green = color.green * 2 / 3;
color.blue = color.blue * 2 / 3;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gdk_gc_set_rgb_fg_color(inst->uctx.u.gdk.gc, &color);
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#else
/* Poor GTK1 fallback */
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
gdk_gc_set_foreground(inst->uctx.u.gdk.gc, &inst->cols[256]);
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#endif
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_set_source_rgb_dim(inst->uctx.u.cairo.cr, orgb.r / 255.0,
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
orgb.g / 255.0, orgb.b / 255.0, dim);
}
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
#endif
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void draw_rectangle(GtkFrontend *inst, bool filled,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
int x, int y, int w, int h)
{
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
gdk_draw_rectangle(inst->uctx.u.gdk.target, inst->uctx.u.gdk.gc,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
filled, x, y, w, h);
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_new_path(inst->uctx.u.cairo.cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
if (filled) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
cairo_rectangle(inst->uctx.u.cairo.cr, x, y, w, h);
cairo_fill(inst->uctx.u.cairo.cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
} else {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
cairo_rectangle(inst->uctx.u.cairo.cr,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x + 0.5, y + 0.5, w, h);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
cairo_close_path(inst->uctx.u.cairo.cr);
cairo_stroke(inst->uctx.u.cairo.cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
}
#endif
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_clip(GtkFrontend *inst, int x, int y, int w, int h)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GdkRectangle r;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
r.x = x;
r.y = y;
r.width = w;
r.height = h;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
gdk_gc_set_clip_rectangle(inst->uctx.u.gdk.gc, &r);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_reset_clip(inst->uctx.u.cairo.cr);
cairo_new_path(inst->uctx.u.cairo.cr);
cairo_rectangle(inst->uctx.u.cairo.cr, x, y, w, h);
cairo_clip(inst->uctx.u.cairo.cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_point(GtkFrontend *inst, int x, int y)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
gdk_draw_point(inst->uctx.u.gdk.target, inst->uctx.u.gdk.gc, x, y);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_new_path(inst->uctx.u.cairo.cr);
cairo_rectangle(inst->uctx.u.cairo.cr, x, y, 1, 1);
cairo_fill(inst->uctx.u.cairo.cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_line(GtkFrontend *inst, int x0, int y0, int x1, int y1)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
#ifdef DRAW_TEXT_GDK
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
gdk_draw_line(inst->uctx.u.gdk.target, inst->uctx.u.gdk.gc,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x0, y0, x1, y1);
}
#endif
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_new_path(inst->uctx.u.cairo.cr);
cairo_move_to(inst->uctx.u.cairo.cr, x0 + 0.5, y0 + 0.5);
cairo_line_to(inst->uctx.u.cairo.cr, x1 + 0.5, y1 + 0.5);
cairo_stroke(inst->uctx.u.cairo.cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_stretch_before(GtkFrontend *inst, int x, int y,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int w, bool wdouble,
int h, bool hdouble, bool hbothalf)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
cairo_matrix_t matrix;
matrix.xy = 0;
matrix.yx = 0;
if (wdouble) {
matrix.xx = 2;
matrix.x0 = -x;
} else {
matrix.xx = 1;
matrix.x0 = 0;
}
if (hdouble) {
matrix.yy = 2;
if (hbothalf) {
matrix.y0 = -(y+h);
} else {
matrix.y0 = -y;
}
} else {
matrix.yy = 1;
matrix.y0 = 0;
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
cairo_transform(inst->uctx.u.cairo.cr, &matrix);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_stretch_after(GtkFrontend *inst, int x, int y,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int w, bool wdouble,
int h, bool hdouble, bool hbothalf)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
#ifdef DRAW_TEXT_GDK
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#ifndef NO_BACKING_PIXMAPS
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_GDK) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* I can't find any plausible StretchBlt equivalent in the X
* server, so I'm going to do this the slow and painful way.
* This will involve repeated calls to gdk_draw_pixmap() to
* stretch the text horizontally. It's O(N^2) in time and O(N)
* in network bandwidth, but you try thinking of a better way.
* :-(
*/
int i;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
if (wdouble) {
for (i = 0; i < w; i++) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
gdk_draw_pixmap(inst->uctx.u.gdk.target,
inst->uctx.u.gdk.gc,
inst->uctx.u.gdk.target,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x + 2*i, y,
x + 2*i+1, y,
w - i, h);
}
w *= 2;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (hdouble) {
int dt, db;
/* Now stretch vertically, in the same way. */
if (hbothalf)
dt = 0, db = 1;
else
dt = 1, db = 0;
for (i = 0; i < h; i += 2) {
gdk_draw_pixmap(inst->uctx.u.gdk.target,
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst->uctx.u.gdk.gc,
inst->uctx.u.gdk.target,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x, y + dt*i + db,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x, y + dt*(i+1),
w, h-i-1);
}
}
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#else
#error No way to implement stretching in GDK without a reliable backing pixmap
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#endif
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 08:02:31 +00:00
#endif /* DRAW_TEXT_GDK */
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifdef DRAW_TEXT_CAIRO
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (inst->uctx.type == DRAWTYPE_CAIRO) {
cairo_set_matrix(inst->uctx.u.cairo.cr,
&inst->uctx.u.cairo.origmatrix);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
#endif
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void draw_backing_rect(GtkFrontend *inst)
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (!win_setup_draw_ctx(&inst->termwin))
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
return;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
draw_set_colour(inst, 258, false);
GTK: fix junk in window margin with fixed-size windows. When the window can't be resized for any reason, there will be extra space inside the drawing area that's not part of our standard width*font_width+2*window_border. We should include that in the backing surface and make sure we erase it to the background colour, otherwise it can end up containing unwanted visual junk. An example is the same case described in the previous commit: maximise the window and then start playing about with the font size. If you do this while running a full-screen application that displays text in the bottom line, it's easy to see that part of the previous display is left over and not cleared when the new font size leaves more space at the bottom than the old one.
2022-02-03 17:56:38 +00:00
draw_rectangle(inst, true, 0, 0, inst->backing_w, inst->backing_h);
draw_update(inst, 0, 0, inst->backing_w, inst->backing_h);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
win_free_draw_ctx(&inst->termwin);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
}
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
/*
* Draw a line of text in the window, at given character
* coordinates, in given attributes.
*
* We are allowed to fiddle with the contents of `text'.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void do_text_internal(
GtkFrontend *inst, int x, int y, wchar_t *text, int len,
unsigned long attr, int lattr, truecolour truecolour)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Fix combining character handling in Pango. 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.
2015-09-26 09:18:53 +00:00
int ncombining;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int nfg, nbg, t, fontid, rlen, widefactor;
bool bold;
bool monochrome =
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
gdk_visual_get_depth(gtk_widget_get_visual(inst->area)) == 1;
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
if (attr & TATTR_COMBINING) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ncombining = len;
len = 1;
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ncombining = 1;
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
Disable true colour on monochrome or paletted displays. I'm not sure if any X11 monochrome visuals or Windows paletted display modes are still around, but just in case they are, we shouldn't attempt true colour on either kind of display.
2017-10-05 19:30:09 +00:00
if (monochrome)
truecolour.fg = truecolour.bg = optionalrgb_none;
On 1bpp displays, ignore colour attributes. This makes pterm minimally useful there, though (e.g.) switching to using reverse video for the cursor would probably also help. Displays with other silly depths (e.g. 2bpp) aren't catered for, but I suspect they're rare in the X world. [originally from svn r5696]
2005-04-27 21:09:45 +00:00
nfg = ((monochrome ? ATTR_DEFFG : (attr & ATTR_FGMASK)) >> ATTR_FGSHIFT);
nbg = ((monochrome ? ATTR_DEFBG : (attr & ATTR_BGMASK)) >> ATTR_BGSHIFT);
On monochrome displays, display the cursor in reverse video so that it's visible on reversed out text. This only applies to active block cursors for now. [originally from svn r5698]
2005-04-27 21:42:51 +00:00
if (!!(attr & ATTR_REVERSE) ^ (monochrome && (attr & TATTR_ACTCURS))) {
Make reverse video interact correctly with true colour. ATTR_REVERSE was being handled in the front ends, and was causing the foreground and background colours to be switched. (I'm not completely sure why I made that design decision; it might be purely historical, but then again, it might also be because reverse video is one effect on the fg and bg colours that must still be performed even in unusual frontend-specific situations like display-driven monochrome mode.) This affected both explicit reverse video enabled using SGR 7, and also the transient reverse video arising from mouse selection. Thanks to Markus Gans for reporting the bug in the latter, which when I investigated it turned out to affect the former as well.
2017-10-08 12:49:54 +00:00
struct optionalrgb trgb;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
t = nfg;
nfg = nbg;
nbg = t;
Make reverse video interact correctly with true colour. ATTR_REVERSE was being handled in the front ends, and was causing the foreground and background colours to be switched. (I'm not completely sure why I made that design decision; it might be purely historical, but then again, it might also be because reverse video is one effect on the fg and bg colours that must still be performed even in unusual frontend-specific situations like display-driven monochrome mode.) This affected both explicit reverse video enabled using SGR 7, and also the transient reverse video arising from mouse selection. Thanks to Markus Gans for reporting the bug in the latter, which when I investigated it turned out to affect the former as well.
2017-10-08 12:49:54 +00:00
trgb = truecolour.fg;
truecolour.fg = truecolour.bg;
truecolour.bg = trgb;
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
}
Cleanup: make symbolic names for CONF_bold_style bits. CONF_bold_style is a pair of bit flags rather than an enum, so its values aren't just BOLD_STYLE_FONT and BOLD_STYLE_COLOUR but also the bitwise OR of them. (Hopefully not neither.)
2023-05-29 14:51:56 +00:00
if ((inst->bold_style & BOLD_STYLE_COLOUR) && (attr & ATTR_BOLD)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (nfg < 16) nfg |= 8;
else if (nfg >= 256) nfg |= 1;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
}
Cleanup: make symbolic names for CONF_bold_style bits. CONF_bold_style is a pair of bit flags rather than an enum, so its values aren't just BOLD_STYLE_FONT and BOLD_STYLE_COLOUR but also the bitwise OR of them. (Hopefully not neither.)
2023-05-29 14:51:56 +00:00
if ((inst->bold_style & BOLD_STYLE_COLOUR) && (attr & ATTR_BLINK)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (nbg < 16) nbg |= 8;
else if (nbg >= 256) nbg |= 1;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
}
On monochrome displays, display the cursor in reverse video so that it's visible on reversed out text. This only applies to active block cursors for now. [originally from svn r5698]
2005-04-27 21:42:51 +00:00
if ((attr & TATTR_ACTCURS) && !monochrome) {
Make the cursor colour override true colour. Otherwise, moving the cursor (at least in active, filled-cell mode) on to a true-coloured character cell causes it to vanish completely because the cell's colours override the thing that differentiates the cursor.
2017-10-05 19:30:04 +00:00
truecolour.fg = truecolour.bg = optionalrgb_none;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nfg = 260;
nbg = 261;
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
attr &= ~ATTR_DIM; /* don't dim the cursor */
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
fontid = 0;
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
if (attr & ATTR_WIDE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
widefactor = 2;
fontid |= 2;
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
widefactor = 1;
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
}
Cleanup: make symbolic names for CONF_bold_style bits. CONF_bold_style is a pair of bit flags rather than an enum, so its values aren't just BOLD_STYLE_FONT and BOLD_STYLE_COLOUR but also the bitwise OR of them. (Hopefully not neither.)
2023-05-29 14:51:56 +00:00
if ((attr & ATTR_BOLD) && (inst->bold_style & BOLD_STYLE_FONT)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bold = true;
fontid |= 1;
Refactor the font handling code: I've moved all the code that 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]
2008-03-22 11:40:23 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bold = false;
Refactor the font handling code: I've moved all the code that 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]
2008-03-22 11:40:23 +00:00
}
if (!inst->fonts[fontid]) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
/*
* Fall back through font ids with subsets of this one's
* set bits, in order.
*/
for (i = fontid; i-- > 0 ;) {
if (i & ~fontid)
continue; /* some other bit is set */
if (inst->fonts[i]) {
fontid = i;
break;
}
}
assert(inst->fonts[fontid]); /* we should at least have hit zero */
Support bold-as-font, by means of a separate bold font (if one was supplied) or shadow bolding (if not). As usual, can't yet be turned on without a recompile. [originally from svn r2077]
2002-10-15 18:42:48 +00:00
}
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x *= 2;
if (x >= inst->term->cols)
return;
if (x + len*2*widefactor > inst->term->cols) {
len = (inst->term->cols-x)/2/widefactor;/* trim to LH half */
Fix crash on ESC#6 + combining chars + GTK + odd-width terminal. When we're displaying double-width text as a result of the VT100 ESC#6 escape sequence or its friends, and the terminal width is an odd number of columns, we divide by 2 the number of characters we'll even try to display, and round _down_: if there's a rightmost odd column, it stays blank, and doesn't show the left half of a double-width char. In the GTK redraw function, that rounding-down can set the 'len' variable to zero. But when we're displaying a character with Unicode combining chars on top, that fails an assertion that len == 1, because at the top of the function we set it to 1. The fix is just to return early if len is reduced to zero by that rounding: if we're not displaying any characters, then we don't have to do anything at all.
2019-02-14 18:05:22 +00:00
if (len == 0)
return; /* rounded down half a double-width char to zero */
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
rlen = len * 2;
Improve shadow bold mode: set the default shadow bold offset to +1 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]
2002-11-02 16:16:35 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
rlen = len;
Improve shadow bold mode: set the default shadow bold offset to +1 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]
2002-11-02 16:16:35 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
draw_clip(inst,
Call draw_stretch_before *after* setting up the clip region. A small bug in yesterday's work: since in Cairo mode draw_stretch_before changes the transformation matrix, if we do it before calling draw_clip then the clip region will be interpreted in the transformed coordinates. This caused a subtle display bug in yesterday's commit: drawing one half of double-height text would have drawn _both_ halves of it on to the window's backing pixmap, but only copied the correct half on to the window proper - but the overdrawing on the pixmap would have shown up if the window was hidden and re-exposed.
2015-08-16 07:55:04 +00:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
rlen*widefactor*inst->font_width,
inst->font_height);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
draw_stretch_before(inst,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
rlen*widefactor*inst->font_width, true,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
inst->font_height,
((lattr & LATTR_MODE) != LATTR_WIDE),
((lattr & LATTR_MODE) == LATTR_BOT));
}
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
if (truecolour.bg.enabled)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
draw_set_colour_rgb(inst, truecolour.bg, attr & ATTR_DIM);
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
draw_set_colour(inst, nbg, attr & ATTR_DIM);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
draw_rectangle(inst, true,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
rlen*widefactor*inst->font_width, inst->font_height);
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
if (truecolour.fg.enabled)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
draw_set_colour_rgb(inst, truecolour.fg, attr & ATTR_DIM);
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
draw_set_colour(inst, nfg, attr & ATTR_DIM);
Fix combining character handling in Pango. 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.
2015-09-26 09:18:53 +00:00
if (ncombining > 1) {
assert(len == 1);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
unifont_draw_combining(&inst->uctx, inst->fonts[fontid],
Fix combining character handling in Pango. 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.
2015-09-26 09:18:53 +00:00
x*inst->font_width+inst->window_border,
(y*inst->font_height+inst->window_border+
inst->fonts[0]->ascent),
text, ncombining, widefactor > 1,
bold, inst->font_width);
} else {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
unifont_draw_text(&inst->uctx, inst->fonts[fontid],
Change the unifont API so that text is passed right down to the 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]
2011-09-16 19:18:53 +00:00
x*inst->font_width+inst->window_border,
Fix combining character handling in Pango. 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.
2015-09-26 09:18:53 +00:00
(y*inst->font_height+inst->window_border+
inst->fonts[0]->ascent),
text, len, widefactor > 1,
Change the unifont API so that text is passed right down to the 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]
2011-09-16 19:18:53 +00:00
bold, inst->font_width);
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 12:20:34 +00:00
}
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
if (attr & ATTR_UNDER) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int uheight = inst->fonts[0]->ascent + 1;
if (uheight >= inst->font_height)
uheight = inst->font_height - 1;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
draw_line(inst, x*inst->font_width+inst->window_border,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
y*inst->font_height + uheight + inst->window_border,
(x+len)*widefactor*inst->font_width-1+inst->window_border,
y*inst->font_height + uheight + inst->window_border);
Support SGR 9 for strikethrough effect on text. This is mostly easy: it's just like drawing an underline, except that you put it at a different height in the character cell. The only question is _where_ in the character cell. Pango, and Windows GetOutlineTextMetrics, will tell you exactly where the font wants to have it. Following xterm, I fall back to 3/8 of the font's ascent (above the baseline) if either of those is unavailable.
2020-08-13 20:08:53 +00:00
}
if (attr & ATTR_STRIKE) {
int sheight = inst->fonts[fontid]->strikethrough_y;
draw_line(inst, x*inst->font_width+inst->window_border,
y*inst->font_height + sheight + inst->window_border,
(x+len)*widefactor*inst->font_width-1+inst->window_border,
y*inst->font_height + sheight + inst->window_border);
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
}
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
draw_stretch_after(inst,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
rlen*widefactor*inst->font_width, true,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
inst->font_height,
((lattr & LATTR_MODE) != LATTR_WIDE),
((lattr & LATTR_MODE) == LATTR_BOT));
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
}
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_draw_text(
TermWin *tw, int x, int y, wchar_t *text, int len,
unsigned long attr, int lattr, truecolour truecolour)
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
int widefactor;
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
do_text_internal(inst, x, y, text, len, attr, lattr, truecolour);
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
if (attr & ATTR_WIDE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
widefactor = 2;
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
widefactor = 1;
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
}
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x *= 2;
if (x >= inst->term->cols)
return;
if (x + len*2*widefactor > inst->term->cols)
len = (inst->term->cols-x)/2/widefactor;/* trim to LH half */
len *= 2;
Support for line attributes: ESC #3, #4 and #6 for double-width and double-height text. [originally from svn r2054]
2002-10-15 00:22:48 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
draw_update(inst,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
len*widefactor*inst->font_width, inst->font_height);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void gtkwin_draw_cursor(
TermWin *tw, int x, int y, wchar_t *text, int len,
unsigned long attr, int lattr, truecolour truecolour)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool active, passive;
int widefactor;
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
if (attr & TATTR_PASCURS) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
attr &= ~TATTR_PASCURS;
passive = true;
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
passive = false;
Cleanup: make an enum for the values of CONF_cursor_type. These have been magic numbers 0, 1 and 2 in the source for ages. I think it's about time they had actual names, to make all the points of use clearer.
2023-05-29 14:51:17 +00:00
if ((attr & TATTR_ACTCURS) && inst->cursor_type != CURSOR_BLOCK) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
attr &= ~TATTR_ACTCURS;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
active = true;
Line (as opposed to block) cursors were being displayed when they shouldn't have been, including when they were blinked off. Fixes Debian bug #272877. [originally from svn r4586]
2004-09-28 20:42:39 +00:00
} else
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
active = false;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
do_text_internal(inst, x, y, text, len, attr, lattr, truecolour);
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
Fix cursor display on a combined character cell. [originally from svn r4625]
2004-10-15 08:51:57 +00:00
if (attr & TATTR_COMBINING)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
len = 1;
Fix cursor display on a combined character cell. [originally from svn r4625]
2004-10-15 08:51:57 +00:00
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
if (attr & ATTR_WIDE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
widefactor = 2;
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
widefactor = 1;
Support for double-width (CJK) characters, using the xterm-like options -fw and -fwb to specify wide and wide-bold fonts. [originally from svn r2412]
2003-01-01 21:53:22 +00:00
}
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x *= 2;
if (x >= inst->term->cols)
return;
if (x + len*2*widefactor > inst->term->cols)
len = (inst->term->cols-x)/2/widefactor;/* trim to LH half */
len *= 2;
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
}
Cleanup: make an enum for the values of CONF_cursor_type. These have been magic numbers 0, 1 and 2 in the source for ages. I think it's about time they had actual names, to make all the points of use clearer.
2023-05-29 14:51:17 +00:00
if (inst->cursor_type == CURSOR_BLOCK) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* An active block cursor will already have been done by
* the above do_text call, so we only need to do anything
* if it's passive.
*/
if (passive) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
draw_set_colour(inst, 261, false);
draw_rectangle(inst, false,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
len*widefactor*inst->font_width-1,
inst->font_height-1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int uheight;
int startx, starty, dx, dy, length, i;
int char_width;
if ((attr & ATTR_WIDE) || (lattr & LATTR_MODE) != LATTR_NORM)
char_width = 2*inst->font_width;
else
char_width = inst->font_width;
Cleanup: make an enum for the values of CONF_cursor_type. These have been magic numbers 0, 1 and 2 in the source for ages. I think it's about time they had actual names, to make all the points of use clearer.
2023-05-29 14:51:17 +00:00
if (inst->cursor_type == CURSOR_UNDERLINE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uheight = inst->fonts[0]->ascent + 1;
if (uheight >= inst->font_height)
uheight = inst->font_height - 1;
startx = x * inst->font_width + inst->window_border;
starty = y * inst->font_height + inst->window_border + uheight;
dx = 1;
dy = 0;
length = len * widefactor * char_width;
Cleanup: make an enum for the values of CONF_cursor_type. These have been magic numbers 0, 1 and 2 in the source for ages. I think it's about time they had actual names, to make all the points of use clearer.
2023-05-29 14:51:17 +00:00
} else /* inst->cursor_type == CURSOR_VERTICAL_LINE */ {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int xadjust = 0;
if (attr & TATTR_RIGHTCURS)
xadjust = char_width - 1;
startx = x * inst->font_width + inst->window_border + xadjust;
starty = y * inst->font_height + inst->window_border;
dx = 0;
dy = 1;
length = inst->font_height;
}
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
draw_set_colour(inst, 261, false);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (passive) {
for (i = 0; i < length; i++) {
if (i % 2 == 0) {
draw_point(inst, startx, starty);
}
startx += dx;
starty += dy;
}
} else if (active) {
draw_line(inst, startx, starty,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
startx + (length-1) * dx, starty + (length-1) * dy);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} /* else no cursor (e.g., blinked off) */
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
}
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 18:18:25 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
draw_update(inst,
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
len*widefactor*inst->font_width, inst->font_height);
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
{
GdkRectangle cursorrect;
cursorrect.x = x*inst->font_width+inst->window_border;
cursorrect.y = y*inst->font_height+inst->window_border;
cursorrect.width = len*widefactor*inst->font_width;
cursorrect.height = inst->font_height;
gtk_im_context_set_cursor_location(inst->imc, &cursorrect);
}
#endif
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
}
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
/*
* For GTK 1, manual code to scale an in-memory XPM, producing a new
* one as output. It will be ugly, but good enough to use as a trust
* sigil.
*/
struct XpmHolder {
char **strings;
size_t nstrings;
};
static void xpmholder_free(XpmHolder *xh)
{
for (size_t i = 0; i < xh->nstrings; i++)
sfree(xh->strings[i]);
sfree(xh->strings);
sfree(xh);
}
static XpmHolder *xpm_scale(const char *const *xpm, int wo, int ho)
{
/* Get image dimensions, # colours, and chars-per-pixel */
int wi = 0, hi = 0, nc = 0, cpp = 0;
int retd = sscanf(xpm[0], "%d %d %d %d", &wi, &hi, &nc, &cpp);
assert(retd == 4);
/* Make output XpmHolder */
XpmHolder *xh = snew(XpmHolder);
xh->nstrings = 1 + nc + ho;
xh->strings = snewn(xh->nstrings, char *);
/* Set up header */
xh->strings[0] = dupprintf("%d %d %d %d", wo, ho, nc, cpp);
for (int i = 0; i < nc; i++)
xh->strings[1 + i] = dupstr(xpm[1 + i]);
/* Scale image */
for (int yo = 0; yo < ho; yo++) {
int yi = yo * hi / ho;
char *ro = snewn(cpp * wo + 1, char);
ro[cpp * wo] = '\0';
xh->strings[1 + nc + yo] = ro;
const char *ri = xpm[1 + nc + yi];
for (int xo = 0; xo < wo; xo++) {
int xi = xo * wi / wo;
memcpy(ro + cpp * xo, ri + cpp * xi, cpp);
}
}
return xh;
}
#endif /* !GTK_CHECK_VERSION(2,0,0) */
static void gtkwin_draw_trust_sigil(TermWin *tw, int cx, int cy)
{
GtkFrontend *inst = container_of(tw, GtkFrontend, termwin);
int x = cx * inst->font_width + inst->window_border;
int y = cy * inst->font_height + inst->window_border;
int w = 2*inst->font_width, h = inst->font_height;
if (inst->trust_sigil_w != w || inst->trust_sigil_h != h ||
#if GTK_CHECK_VERSION(2,0,0)
!inst->trust_sigil_pb
#else
!inst->trust_sigil_pm
#endif
) {
#if GTK_CHECK_VERSION(2,0,0)
if (inst->trust_sigil_pb)
g_object_unref(G_OBJECT(inst->trust_sigil_pb));
#else
if (inst->trust_sigil_pm)
gdk_pixmap_unref(inst->trust_sigil_pm);
#endif
int best_icon_index = 0;
unsigned score = UINT_MAX;
for (int i = 0; i < n_main_icon; i++) {
int iw, ih;
if (sscanf(main_icon[i][0], "%d %d", &iw, &ih) == 2) {
int this_excess = (iw + ih) - (w + h);
unsigned this_score = (abs(this_excess) |
(this_excess > 0 ? 0 : 0x80000000U));
if (this_score < score) {
best_icon_index = i;
score = this_score;
}
}
}
#if GTK_CHECK_VERSION(2,0,0)
GdkPixbuf *icon_unscaled = gdk_pixbuf_new_from_xpm_data(
(const gchar **)main_icon[best_icon_index]);
inst->trust_sigil_pb = gdk_pixbuf_scale_simple(
icon_unscaled, w, h, GDK_INTERP_BILINEAR);
g_object_unref(G_OBJECT(icon_unscaled));
#else
XpmHolder *xh = xpm_scale(main_icon[best_icon_index], w, h);
inst->trust_sigil_pm = gdk_pixmap_create_from_xpm_d(
gtk_widget_get_window(inst->window), NULL,
&inst->cols[258], xh->strings);
xpmholder_free(xh);
#endif
inst->trust_sigil_w = w;
inst->trust_sigil_h = h;
}
#ifdef DRAW_TEXT_GDK
if (inst->uctx.type == DRAWTYPE_GDK) {
#if GTK_CHECK_VERSION(2,0,0)
gdk_draw_pixbuf(inst->uctx.u.gdk.target, inst->uctx.u.gdk.gc,
inst->trust_sigil_pb, 0, 0, x, y, w, h,
GDK_RGB_DITHER_NORMAL, 0, 0);
#else
gdk_draw_pixmap(inst->uctx.u.gdk.target, inst->uctx.u.gdk.gc,
inst->trust_sigil_pm, 0, 0, x, y, w, h);
#endif
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (inst->uctx.type == DRAWTYPE_CAIRO) {
inst->uctx.u.cairo.widget = GTK_WIDGET(inst->area);
cairo_save(inst->uctx.u.cairo.cr);
cairo_translate(inst->uctx.u.cairo.cr, x, y);
gdk_cairo_set_source_pixbuf(inst->uctx.u.cairo.cr,
inst->trust_sigil_pb, 0, 0);
cairo_rectangle(inst->uctx.u.cairo.cr, 0, 0, w, h);
cairo_fill(inst->uctx.u.cairo.cr);
cairo_restore(inst->uctx.u.cairo.cr);
}
#endif
draw_update(inst, x, y, w, h);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GdkCursor *make_mouse_ptr(GtkFrontend *inst, int cursor_val)
Deal with the appalling mouse pointer colours. (Why doesn't GTK let 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]
2002-10-13 12:17:03 +00:00
{
Withdraw the horrible bodge in make_mouse_ptr(). We were previously building our own mouse pointers out of pixmaps, having first drawn characters from the X server standard font 'cursor' on to those pixmaps, giving an effect almost exactly the same as just calling gdk_cursor_new(some constant) except that we got to choose the foreground and background colours of the resulting pointers. But it's not clear why we needed to do that! In both GTK1 and GTK2 as of my current testing, the standard colours appear to be just what I wanted anyway (white pointer with black outline). The previous implementation (and commit comment) was written in 2002, so perhaps it was working around a GTK1 bug of the time. So I've removed it completely, and replaced it with simple calls to gdk_cursor_new (plus a workaround for GTK1's lack of GDK_BLANK_CURSOR, but that's still much simpler than the previous code). If anyone does report a colour problem, I may have to go back to doing something clever, but if I can possibly arrange it, I'll want to do it by some other technique, probably (as suggested in a comment in the previous implementation) getting the underlying X cursor id and calling XRecolorCursor.
2015-08-15 20:07:35 +00:00
if (cursor_val == -1) {
#if GTK_CHECK_VERSION(2,16,0)
cursor_val = GDK_BLANK_CURSOR;
#else
/*
* Work around absence of GDK_BLANK_CURSOR by inventing a
* blank pixmap.
*/
GdkCursor *ret;
GdkColor bg = { 0, 0, 0, 0 };
GdkPixmap *pm = gdk_pixmap_new(NULL, 1, 1, 1);
GdkGC *gc = gdk_gc_new(pm);
gdk_gc_set_foreground(gc, &bg);
gdk_draw_rectangle(pm, gc, 1, 0, 0, 1, 1);
gdk_gc_unref(gc);
ret = gdk_cursor_new_from_pixmap(pm, pm, &bg, &bg, 1, 1);
gdk_pixmap_unref(pm);
return ret;
#endif
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 09:58:27 +00:00
}
Deal with the appalling mouse pointer colours. (Why doesn't GTK let 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]
2002-10-13 12:17:03 +00:00
Withdraw the horrible bodge in make_mouse_ptr(). We were previously building our own mouse pointers out of pixmaps, having first drawn characters from the X server standard font 'cursor' on to those pixmaps, giving an effect almost exactly the same as just calling gdk_cursor_new(some constant) except that we got to choose the foreground and background colours of the resulting pointers. But it's not clear why we needed to do that! In both GTK1 and GTK2 as of my current testing, the standard colours appear to be just what I wanted anyway (white pointer with black outline). The previous implementation (and commit comment) was written in 2002, so perhaps it was working around a GTK1 bug of the time. So I've removed it completely, and replaced it with simple calls to gdk_cursor_new (plus a workaround for GTK1's lack of GDK_BLANK_CURSOR, but that's still much simpler than the previous code). If anyone does report a colour problem, I may have to go back to doing something clever, but if I can possibly arrange it, I'll want to do it by some other technique, probably (as suggested in a comment in the previous implementation) getting the underlying X cursor id and calling XRecolorCursor.
2015-08-15 20:07:35 +00:00
return gdk_cursor_new(cursor_val);
Deal with the appalling mouse pointer colours. (Why doesn't GTK let 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]
2002-10-13 12:17:03 +00:00
}
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void modalfatalbox(const char *p, ...)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
va_list ap;
fprintf(stderr, "FATAL ERROR: ");
va_start(ap, p);
vfprintf(stderr, p, ap);
va_end(ap);
fputc('\n', stderr);
exit(1);
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
}
Avoid treating non-X GDK display names as X ones When running on Wayland, gdk_display_get_name() can return things like "wayland-0" rather than valid X display names. PuTTY nonetheless treated them as X display names, meaning that when running under Wayland, pterm would set DISPLAY to "wayland-0" in subprocesses, and PuTTY's X forwarding wouldn't work properly. To fix this, places that call gdk_display_get_name() now only do so on displays for which GDK_IS_X_DISPLAY() is true. As with GDK_IS_X_WINDOW(), this requires some backward-compatibility for GDK versions where everything is implicitly running on X. To make this work usefully, pterm now also won't unset DISPLAY if it can't get an X display name and instead will pass through whatever value of DISPLAY it received. I think that's better behaviour anyway. There are two separate parts of PuTTY that call gdk_display_get_name(). platform_get_x_display() in unix/putty.c is used for X forwarding, while gtk_seat_get_x_display() in unix/window.c is used used for setting DISPLAY and recording in utmp. I've updated both of them.
2023-07-15 20:05:41 +00:00
#ifndef NOT_X_WINDOWS
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static const char *gtk_seat_get_x_display(Seat *seat)
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
{
Avoid treating non-X GDK display names as X ones When running on Wayland, gdk_display_get_name() can return things like "wayland-0" rather than valid X display names. PuTTY nonetheless treated them as X display names, meaning that when running under Wayland, pterm would set DISPLAY to "wayland-0" in subprocesses, and PuTTY's X forwarding wouldn't work properly. To fix this, places that call gdk_display_get_name() now only do so on displays for which GDK_IS_X_DISPLAY() is true. As with GDK_IS_X_WINDOW(), this requires some backward-compatibility for GDK versions where everything is implicitly running on X. To make this work usefully, pterm now also won't unset DISPLAY if it can't get an X display name and instead will pass through whatever value of DISPLAY it received. I think that's better behaviour anyway. There are two separate parts of PuTTY that call gdk_display_get_name(). platform_get_x_display() in unix/putty.c is used for X forwarding, while gtk_seat_get_x_display() in unix/window.c is used used for setting DISPLAY and recording in utmp. I've updated both of them.
2023-07-15 20:05:41 +00:00
if (GDK_IS_X11_DISPLAY(gdk_display_get_default()))
return gdk_get_display();
return NULL;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool gtk_seat_get_windowid(Seat *seat, long *id)
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 12:57:37 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
GdkWindow *window = gtk_widget_get_window(inst->area);
if (!GDK_IS_X11_WINDOW(window))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
*id = GDK_WINDOW_XID(window);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 12:57:37 +00:00
}
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#endif
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 12:57:37 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
char *setup_fonts_ucs(GtkFrontend *inst)
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool shadowbold = conf_get_bool(inst->conf, CONF_shadowbold);
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
int shadowboldoffset = conf_get_int(inst->conf, CONF_shadowboldoffset);
FontSpec *fs;
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
unifont *fonts[4];
int i;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
fs = conf_get_fontspec(inst->conf, CONF_font);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
fonts[0] = multifont_create(inst->area, fs->name, false, false,
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
shadowboldoffset, shadowbold);
if (!fonts[0]) {
return dupprintf("unable to load font \"%s\"", fs->name);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
}
pterm will now attempt to guess suitable names for any missing fonts from the ones given; so it'll ask for a font twice as wide as your base one if you don't specify a wide font, it'll ask for a bolded version of your base font if you don't specify a bold font, and similarly for a wide/bold font. Should solve Debian bug #187389; at least it works for me. [originally from svn r3175]
2003-05-10 10:15:00 +00:00
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
fs = conf_get_fontspec(inst->conf, CONF_boldfont);
if (shadowbold || !fs->name[0]) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fonts[1] = NULL;
pterm will now attempt to guess suitable names for any missing fonts from the ones given; so it'll ask for a font twice as wide as your base one if you don't specify a wide font, it'll ask for a bolded version of your base font if you don't specify a bold font, and similarly for a wide/bold font. Should solve Debian bug #187389; at least it works for me. [originally from svn r3175]
2003-05-10 10:15:00 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fonts[1] = multifont_create(inst->area, fs->name, false, true,
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
shadowboldoffset, shadowbold);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!fonts[1]) {
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
if (fonts[0])
unifont_destroy(fonts[0]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return dupprintf("unable to load bold font \"%s\"", fs->name);
}
pterm will now attempt to guess suitable names for any missing fonts from the ones given; so it'll ask for a font twice as wide as your base one if you don't specify a wide font, it'll ask for a bolded version of your base font if you don't specify a bold font, and similarly for a wide/bold font. Should solve Debian bug #187389; at least it works for me. [originally from svn r3175]
2003-05-10 10:15:00 +00:00
}
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
fs = conf_get_fontspec(inst->conf, CONF_widefont);
if (fs->name[0]) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fonts[2] = multifont_create(inst->area, fs->name, true, false,
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
shadowboldoffset, shadowbold);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!fonts[2]) {
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
for (i = 0; i < 2; i++)
if (fonts[i])
unifont_destroy(fonts[i]);
Fix an assortment of dupprintf() format string bugs. I've enabled gcc's format-string checking on dupprintf, by declaring it in misc.h to have the appropriate GNU-specific attribute. This pointed out a selection of warnings, which I've fixed. [originally from svn r10084]
2013-11-17 14:05:44 +00:00
return dupprintf("unable to load wide font \"%s\"", fs->name);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
pterm will now attempt to guess suitable names for any missing fonts from the ones given; so it'll ask for a font twice as wide as your base one if you don't specify a wide font, it'll ask for a bolded version of your base font if you don't specify a bold font, and similarly for a wide/bold font. Should solve Debian bug #187389; at least it works for me. [originally from svn r3175]
2003-05-10 10:15:00 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fonts[2] = NULL;
pterm will now attempt to guess suitable names for any missing fonts from the ones given; so it'll ask for a font twice as wide as your base one if you don't specify a wide font, it'll ask for a bolded version of your base font if you don't specify a bold font, and similarly for a wide/bold font. Should solve Debian bug #187389; at least it works for me. [originally from svn r3175]
2003-05-10 10:15:00 +00:00
}
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
fs = conf_get_fontspec(inst->conf, CONF_wideboldfont);
if (shadowbold || !fs->name[0]) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fonts[3] = NULL;
pterm will now attempt to guess suitable names for any missing fonts from the ones given; so it'll ask for a font twice as wide as your base one if you don't specify a wide font, it'll ask for a bolded version of your base font if you don't specify a bold font, and similarly for a wide/bold font. Should solve Debian bug #187389; at least it works for me. [originally from svn r3175]
2003-05-10 10:15:00 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fonts[3] = multifont_create(inst->area, fs->name, true, true,
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
shadowboldoffset, shadowbold);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!fonts[3]) {
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
for (i = 0; i < 3; i++)
if (fonts[i])
unifont_destroy(fonts[i]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return dupprintf("unable to load wide bold font \"%s\"", fs->name);
}
pterm will now attempt to guess suitable names for any missing fonts from the ones given; so it'll ask for a font twice as wide as your base one if you don't specify a wide font, it'll ask for a bolded version of your base font if you don't specify a bold font, and similarly for a wide/bold font. Should solve Debian bug #187389; at least it works for me. [originally from svn r3175]
2003-05-10 10:15:00 +00:00
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
/*
* Now we've got past all the possible error conditions, we can
* actually update our state.
*/
for (i = 0; i < 4; i++) {
if (inst->fonts[i])
unifont_destroy(inst->fonts[i]);
inst->fonts[i] = fonts[i];
}
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
if (inst->font_width != inst->fonts[0]->width ||
inst->font_height != inst->fonts[0]->height) {
inst->font_width = inst->fonts[0]->width;
inst->font_height = inst->fonts[0]->height;
/*
* The font size has changed, so force the next call to
* drawing_area_setup to regenerate the backing surface.
*/
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->drawing_area_setup_needed = true;
GTK: remember to resize backing surface on a font change. Changing the window's font size with Alt-< or Alt-> was not setting any of the flags that make drawing_area_setup consider itself to have been non-spuriously called, so the real window would enlarge without the backing surface also doing so.
2018-05-17 10:20:01 +00:00
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
inst->direct_to_font = init_ucs(&inst->ucsdata,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_get_str(inst->conf, CONF_line_codepage),
conf_get_bool(inst->conf, CONF_utf8_override),
inst->fonts[0]->public_charset,
conf_get_int(inst->conf, CONF_vtmode));
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
inst->drawtype = inst->fonts[0]->preferred_drawtype;
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
return NULL;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
}
Account for GtkApplicationWindow menu bar in geometry hints. 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.
2016-04-04 10:28:34 +00:00
#if GTK_CHECK_VERSION(3,0,0)
struct find_app_menu_bar_ctx {
GtkWidget *area, *menubar;
};
static void find_app_menu_bar(GtkWidget *widget, gpointer data)
{
struct find_app_menu_bar_ctx *ctx = (struct find_app_menu_bar_ctx *)data;
if (widget != ctx->area && GTK_IS_MENU_BAR(widget))
ctx->menubar = widget;
}
#endif
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void compute_geom_hints(GtkFrontend *inst, GdkGeometry *geom)
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
{
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
/*
* Unused fields in geom.
*/
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
geom->max_width = geom->max_height = -1;
geom->min_aspect = geom->max_aspect = 0;
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
/*
* Set up the geometry fields we care about, with reference to
Account for GtkApplicationWindow menu bar in geometry hints. 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.
2016-04-04 10:28:34 +00:00
* just the drawing area. We'll correct for other widgets in a
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
* moment.
*/
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
geom->min_width = inst->font_width + 2*inst->window_border;
geom->min_height = inst->font_height + 2*inst->window_border;
geom->base_width = 2*inst->window_border;
geom->base_height = 2*inst->window_border;
geom->width_inc = inst->font_width;
geom->height_inc = inst->font_height;
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
/*
* If we've got a scrollbar visible, then we must include its
* width as part of the base and min width, and also ensure that
* our window's minimum height is at least the height required by
* the scrollbar.
*
* In the latter case, we must also take care to arrange that
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
* (geom->min_height - geom->base_height) is an integer multiple of
* geom->height_inc, because if it's not, then some window managers
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
* (we know of xfwm4) get confused, with the effect that they
* resize our window to a height based on min_height instead of
* base_height, which we then round down and the window ends up
* too short.
*/
if (inst->sbar_visible) {
GtkRequisition req;
int min_sb_height;
#if GTK_CHECK_VERSION(3,0,0)
gtk_widget_get_preferred_size(inst->sbar, &req, NULL);
#else
gtk_widget_size_request(inst->sbar, &req);
#endif
/* Compute rounded-up scrollbar height. */
min_sb_height = req.height;
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
min_sb_height += geom->height_inc - 1;
min_sb_height -= ((min_sb_height - geom->base_height%geom->height_inc)
% geom->height_inc);
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
geom->min_width += req.width;
geom->base_width += req.width;
if (geom->min_height < min_sb_height)
geom->min_height = min_sb_height;
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
}
Account for GtkApplicationWindow menu bar in geometry hints. 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.
2016-04-04 10:28:34 +00:00
#if GTK_CHECK_VERSION(3,0,0)
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* And if we're running a main-gtk-application.c based program and
Account for GtkApplicationWindow menu bar in geometry hints. 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.
2016-04-04 10:28:34 +00:00
* GtkApplicationWindow has given us a menu bar inside the window,
* then we must take that into account as well.
*
* In its unbounded wisdom, GtkApplicationWindow doesn't actually
* give us a direct function call to _find_ the menu bar widget.
* Fortunately, we can find it by enumerating the children of the
* top-level window and looking for one we didn't put there
* ourselves.
*/
{
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
struct find_app_menu_bar_ctx ctx[1];
Account for GtkApplicationWindow menu bar in geometry hints. 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.
2016-04-04 10:28:34 +00:00
ctx->area = inst->area;
ctx->menubar = NULL;
gtk_container_foreach(GTK_CONTAINER(inst->window),
find_app_menu_bar, ctx);
if (ctx->menubar) {
GtkRequisition req;
int min_menu_width;
gtk_widget_get_preferred_size(ctx->menubar, NULL, &req);
/*
* This time, the height adjustment is easy (the menu bar
* sits above everything), but we have to take care with
* the _width_ to ensure we keep min_width and base_width
* congruent modulo width_inc.
*/
geom->min_height += req.height;
geom->base_height += req.height;
min_menu_width = req.width;
min_menu_width += geom->width_inc - 1;
min_menu_width -=
((min_menu_width - geom->base_width%geom->width_inc)
% geom->width_inc);
if (geom->min_width < min_menu_width)
geom->min_width = min_menu_width;
}
}
#endif
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
}
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void set_geom_hints(GtkFrontend *inst)
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
{
GTK: stop using geometry hints when not on X11. While re-testing on Wayland after all this churn of the window resizing code, I discovered that the window constantly came out a few pixels too small, losing a character cell in width and height. This stopped happening once I experimentally stopped setting geometry hints. Source-diving in GTK, it turns out that this is because the GDK Wayland backend is applying the geometry hints to the size of the window including 'margins', which are a very large extra space around a window beyond even the visible 'non-client-area' furniture like the title bar. And I have no idea how you find out the size of those margins, so I can't allow for them in the geometry hints. I also noticed that gtk_window_set_geometry_hints is removed in GTK 4, which suggests that GTK upstream are probably not interested in fiddling with them until they work more usefully (even if they would agree with me that this is a bug in the first place, which I have no idea). A simpler workaround is to avoid setting geometry hints at all on any GDK backend other than X11. So, that's what this commit does. On Wayland (or other backends), the window can now be resized a pixel at a time, and if its size doesn't work out to a whole number of character cells, then you just get some dead space at the edges. Not especially nice, but better than the alternatives I can see. One other job the geometry hints were doing was to forbid resizing if the backend sets the BACKEND_RESIZE_FORBIDDEN flag (which SUPDUP does). That's now done at window creation time, via gtk_window_set_resizable.
2021-12-20 11:06:57 +00:00
/*
* 2021-12-20: I've found that on Ubuntu 20.04 Wayland (using GTK
* 3.24.20), setting geometry hints causes the window size to come
* out wrong. As far as I can tell, that's because the GDK Wayland
* backend internally considers windows to be a lot larger than
* their obvious display size (*even* considering visible window
* furniture like title bars), with an extra margin on every side
* to account for surrounding effects like shadows. And the
* geometry hints like base size and resize increment are applied
* to that larger size rather than the more obvious 'client area'
* size. So when we ask for a window of exactly the size we want,
* it gets modified by GDK based on the geometry hints, but
* applying this extra margin, which causes the size to be a
* little bit too small.
*
* I don't know how you can sensibly find out the size of that
* margin. If I did, I could account for it in the geometry hints.
* But I also see that gtk_window_set_geometry_hints is removed in
* GTK 4, which suggests that probably doing a lot of hard work to
* fix this is not the way forward.
*
* So instead, I simply avoid setting geometry hints at all on any
* GDK backend other than X11, and hopefully that's a workaround.
*/
Fix build failure with -DNOT_X_WINDOWS. The recent window resize fixes introduced an unchecked use of GDK_IS_X11_DISPLAY.
2022-05-14 12:48:35 +00:00
#if GTK_CHECK_VERSION(3,0,0) && !defined NOT_X_WINDOWS
GTK: stop using geometry hints when not on X11. While re-testing on Wayland after all this churn of the window resizing code, I discovered that the window constantly came out a few pixels too small, losing a character cell in width and height. This stopped happening once I experimentally stopped setting geometry hints. Source-diving in GTK, it turns out that this is because the GDK Wayland backend is applying the geometry hints to the size of the window including 'margins', which are a very large extra space around a window beyond even the visible 'non-client-area' furniture like the title bar. And I have no idea how you find out the size of those margins, so I can't allow for them in the geometry hints. I also noticed that gtk_window_set_geometry_hints is removed in GTK 4, which suggests that GTK upstream are probably not interested in fiddling with them until they work more usefully (even if they would agree with me that this is a bug in the first place, which I have no idea). A simpler workaround is to avoid setting geometry hints at all on any GDK backend other than X11. So, that's what this commit does. On Wayland (or other backends), the window can now be resized a pixel at a time, and if its size doesn't work out to a whole number of character cells, then you just get some dead space at the edges. Not especially nice, but better than the alternatives I can see. One other job the geometry hints were doing was to forbid resizing if the backend sets the BACKEND_RESIZE_FORBIDDEN flag (which SUPDUP does). That's now done at window creation time, via gtk_window_set_resizable.
2021-12-20 11:06:57 +00:00
if (!GDK_IS_X11_DISPLAY(gdk_display_get_default()))
return;
#endif
New backend function to disable resizing. Some protocols such as SUPDUP does not support resizing the terminal.
2020-02-14 12:49:56 +00:00
const struct BackendVtable *vt;
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
GdkGeometry geom;
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
gint flags = GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE | GDK_HINT_RESIZE_INC;
GTK: split out the computation part from set_geom_hints. 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.
2016-04-04 10:23:25 +00:00
compute_geom_hints(inst, &geom);
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
#if GTK_CHECK_VERSION(2,0,0)
if (inst->gotpos)
flags |= GDK_HINT_USER_POS;
#endif
New backend function to disable resizing. Some protocols such as SUPDUP does not support resizing the terminal.
2020-02-14 12:49:56 +00:00
vt = backend_vt_from_proto(conf_get_int(inst->conf, CONF_protocol));
if (vt && vt->flags & BACKEND_RESIZE_FORBIDDEN) {
/* Window resizing forbidden. Set both minimum and maximum
* dimensions to be the initial size. */
GTK: fix calculation of fixed window size for SUPDUP. The window size set in the geometry hints when the backend has the BACKEND_RESIZE_FORBIDDEN flag was computed in a simplistic way that forgot to take account of window furniture like scrollbars and menu bars. Now it's computed based on the rest of the geometry hints, which are more accurate.
2021-12-20 10:18:38 +00:00
geom.min_width = geom.base_width + geom.width_inc * inst->width;
geom.min_height = geom.base_height + geom.height_inc * inst->height;
New backend function to disable resizing. Some protocols such as SUPDUP does not support resizing the terminal.
2020-02-14 12:49:56 +00:00
geom.max_width = geom.min_width;
geom.max_height = geom.min_height;
flags |= GDK_HINT_MAX_SIZE;
}
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
gtk_window_set_geometry_hints(GTK_WINDOW(inst->window),
NULL, &geom, flags);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
}
GTK: stop using geometry-based window sizing functions. 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.
2016-04-04 10:24:24 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void compute_whole_window_size(GtkFrontend *inst,
GTK: stop using geometry-based window sizing functions. 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.
2016-04-04 10:24:24 +00:00
int wchars, int hchars,
int *wpix, int *hpix)
{
GdkGeometry geom;
compute_geom_hints(inst, &geom);
if (wpix) *wpix = geom.base_width + wchars * geom.width_inc;
if (hpix) *hpix = geom.base_height + hchars * geom.height_inc;
}
#endif
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
void clear_scrollback_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
term_clrsb(inst->term);
}
void reset_terminal_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
term_pwron(inst->term, true);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
if (inst->ldisc)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ldisc_echoedit_update(inst->ldisc);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
GTK context menu options to copy/paste CLIPBOARD.
2017-12-10 16:25:54 +00:00
void copy_clipboard_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Sort out clipboard-related menu items. The gtkapp.c menu now has a Copy as well as Paste option; those menu items, as well as the corresponding ones on the context menu and Copy All, now address sets of clipboards parametrised between OS X and ordinary GTK in unix.h. Also I've tweaked the wording of the context-menu items to not use the X-specific terminology "CLIPBOARD" on OS X.
2017-12-17 20:35:45 +00:00
static const int clips[] = { MENU_CLIPBOARD };
GTK context menu options to copy/paste CLIPBOARD.
2017-12-10 16:25:54 +00:00
term_request_copy(inst->term, clips, lenof(clips));
}
void paste_clipboard_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Sort out clipboard-related menu items. The gtkapp.c menu now has a Copy as well as Paste option; those menu items, as well as the corresponding ones on the context menu and Copy All, now address sets of clipboards parametrised between OS X and ordinary GTK in unix.h. Also I've tweaked the wording of the context-menu items to not use the X-specific terminology "CLIPBOARD" on OS X.
2017-12-17 20:35:45 +00:00
term_request_paste(inst->term, MENU_CLIPBOARD);
GTK context menu options to copy/paste CLIPBOARD.
2017-12-10 16:25:54 +00:00
}
`Copy All' context-menu item, for what it's worth. [originally from svn r3097]
2003-04-11 17:59:36 +00:00
void copy_all_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Sort out clipboard-related menu items. The gtkapp.c menu now has a Copy as well as Paste option; those menu items, as well as the corresponding ones on the context menu and Copy All, now address sets of clipboards parametrised between OS X and ordinary GTK in unix.h. Also I've tweaked the wording of the context-menu items to not use the X-specific terminology "CLIPBOARD" on OS X.
2017-12-17 20:35:45 +00:00
static const int clips[] = { COPYALL_CLIPBOARDS };
Ability to copy to multiple clipboards at once.
2017-12-10 15:45:45 +00:00
term_copyall(inst->term, clips, lenof(clips));
`Copy All' context-menu item, for what it's worth. [originally from svn r3097]
2003-04-11 17:59:36 +00:00
}
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
void special_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
SessionSpecial *sc = g_object_get_data(G_OBJECT(item), "user-data");
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (inst->backend)
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
backend_special(inst->backend, sc->code, sc->arg);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
void about_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
about_box(inst->window);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
void event_log_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
showeventlog(inst->eventlogstuff, inst->window);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void setup_clipboards(GtkFrontend *inst, Terminal *term, Conf *conf)
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
{
assert(term->mouse_select_clipboards[0] == CLIP_LOCAL);
term->n_mouse_select_clipboards = 1;
term->mouse_select_clipboards[
term->n_mouse_select_clipboards++] = MOUSE_SELECT_CLIPBOARD;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_mouseautocopy)) {
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
term->mouse_select_clipboards[
term->n_mouse_select_clipboards++] = CLIP_CLIPBOARD;
}
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
set_clipboard_atom(inst, CLIP_CUSTOM_1, GDK_NONE);
set_clipboard_atom(inst, CLIP_CUSTOM_2, GDK_NONE);
set_clipboard_atom(inst, CLIP_CUSTOM_3, GDK_NONE);
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
switch (conf_get_int(conf, CONF_mousepaste)) {
case CLIPUI_IMPLICIT:
term->mouse_paste_clipboard = MOUSE_PASTE_CLIPBOARD;
break;
case CLIPUI_EXPLICIT:
term->mouse_paste_clipboard = CLIP_CLIPBOARD;
break;
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
case CLIPUI_CUSTOM:
term->mouse_paste_clipboard = CLIP_CUSTOM_1;
set_clipboard_atom(inst, CLIP_CUSTOM_1,
gdk_atom_intern(
conf_get_str(conf, CONF_mousepaste_custom),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
false));
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
break;
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
default:
term->mouse_paste_clipboard = CLIP_NULL;
break;
}
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
if (conf_get_int(conf, CONF_ctrlshiftins) == CLIPUI_CUSTOM) {
GdkAtom atom = gdk_atom_intern(
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
conf_get_str(conf, CONF_ctrlshiftins_custom), false);
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
struct clipboard_state *state = clipboard_from_atom(inst, atom);
if (state) {
inst->clipboard_ctrlshiftins = state->clipboard;
} else {
inst->clipboard_ctrlshiftins = CLIP_CUSTOM_2;
set_clipboard_atom(inst, CLIP_CUSTOM_2, atom);
}
}
if (conf_get_int(conf, CONF_ctrlshiftcv) == CLIPUI_CUSTOM) {
GdkAtom atom = gdk_atom_intern(
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
conf_get_str(conf, CONF_ctrlshiftcv_custom), false);
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
struct clipboard_state *state = clipboard_from_atom(inst, atom);
if (state) {
inst->clipboard_ctrlshiftins = state->clipboard;
} else {
inst->clipboard_ctrlshiftcv = CLIP_CUSTOM_3;
set_clipboard_atom(inst, CLIP_CUSTOM_3, atom);
}
}
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
}
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
struct after_change_settings_dialog_ctx {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst;
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
Conf *newconf;
};
static void after_change_settings_dialog(void *vctx, int retval);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
void change_settings_menuitem(GtkMenuItem *item, gpointer data)
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
struct after_change_settings_dialog_ctx *ctx;
Expand the dialog registering/unregistering system. Now it has several 'slots', each named for a particular class of subsidiary dialog box that a session window can have at most one of, and register_network_prompt_dialog has a more general name and takes an enum-typed argument identifying a slot. This lets me avoid writing a zillion annoyingly similar function pairs and corresponding snippets of cleanup code in delete_inst.
2017-11-26 16:51:19 +00:00
GtkWidget *dialog;
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
char *title;
Reimplement 'really close session?' as a non-modal message box. I've also moved it out into gtkwin.c, because it seemed easier to do the 'find existing instance of this dialog and raise it' dance there than to split it across source files pointlessly.
2017-11-26 17:21:32 +00:00
if (find_and_raise_dialog(inst, DIALOG_SLOT_RECONFIGURE))
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
return;
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
title = dupcat(appname, " Reconfiguration");
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
ctx = snew(struct after_change_settings_dialog_ctx);
ctx->inst = inst;
ctx->newconf = conf_copy(inst->conf);
Move all window-title management into Terminal. Previously, window title management happened in a bipartisan sort of way: front ends would choose their initial window title once they knew what host name they were connecting to, but then Terminal would override that later if the server set the window title by escape sequences. Now it's all done the same way round: the Terminal object is always where titles are invented, and they only propagate in one direction, from the Terminal to the TermWin. This allows us to avoid duplicating in multiple front ends the logic for what the initial window title should be. The frontend just has to make one initial call to term_setup_window_titles, to tell the terminal what hostname should go in the default title (if the Conf doesn't override even that). Thereafter, all it has to do is respond to the TermWin title-setting methods. Similarly, the logic that handles window-title changes as a result of the Change Settings dialog is also centralised into terminal.c. This involved introducing an extra term_pre_reconfig() call that each frontend can call to modify the Conf that will be used for the GUI configurer; that's where the code now lives that copies the current window title into there. (This also means that GTK PuTTY now behaves consistently with Windows PuTTY on that point; GTK's previous behaviour was less well thought out.) It also means there's no longer any need for Terminal to talk to the front end when a remote query wants to _find out_ the window title: the Terminal knows the answer already. So TermWin's get_title method can go.
2021-02-07 19:59:20 +00:00
term_pre_reconfig(inst->term, ctx->newconf);
Expand the dialog registering/unregistering system. Now it has several 'slots', each named for a particular class of subsidiary dialog box that a session window can have at most one of, and register_network_prompt_dialog has a more general name and takes an enum-typed argument identifying a slot. This lets me avoid writing a zillion annoyingly similar function pairs and corresponding snippets of cleanup code in delete_inst.
2017-11-26 16:51:19 +00:00
dialog = create_config_box(
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
title, ctx->newconf, true,
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
inst->backend ? backend_cfg_info(inst->backend) : 0,
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
after_change_settings_dialog, ctx);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
register_dialog(&inst->seat, DIALOG_SLOT_RECONFIGURE, dialog);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
sfree(title);
}
static void after_change_settings_dialog(void *vctx, int retval)
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
{
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
struct after_change_settings_dialog_ctx ctx =
*(struct after_change_settings_dialog_ctx *)vctx;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = ctx.inst;
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
Conf *oldconf = inst->conf, *newconf = ctx.newconf;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool need_size;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
sfree(vctx); /* we've copied this already */
Protect against multiple Change Settings dialogues. We should probably also arrange to switch to an existing Change Settings if the user selects the menu item and we already have a Change Settings. [originally from svn r5475]
2005-03-10 10:07:27 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
unregister_dialog(&inst->seat, DIALOG_SLOT_RECONFIGURE);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
GTK: fix handling of delete event in Change Settings dialog. If the user closes the Change Settings dialog box using the close button provided by the window manager (or some analogous thing that generates the same X11 event) instead of using the Cancel button within the dialog itself, then after_change_settings_dialog() gets called with retval < 0, which triggers an early return path in which we forget to call unregister_dialog(), and as a result, assertions fail all over the place the _next_ time you try to put up a Change Settings dialog. Also, the early return causes ctx.newconf to be memory-leaked. So rather than just moving the unregister_dialog() call to above the early return, a better fix is to remove the early return completely, and simply treat retval<0 the same as retval==0: it doesn't matter _how_ the user closed the config box without committing the changes, it only matters that they did.
2019-06-03 18:05:00 +00:00
if (retval > 0) {
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
inst->conf = newconf;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
/* Pass new config data to the logging module */
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
log_reconfig(inst->logctx, inst->conf);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
/*
* Flush the line discipline's edit buffer in the case
* where local editing has just been disabled.
*/
Add some missing null checks for inst->ldisc, which were causing 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]
2013-07-11 17:24:20 +00:00
if (inst->ldisc) {
ldisc_configure(inst->ldisc, inst->conf);
Move echo/edit state change functionality out of ldisc_send. I'm not actually sure why we've always had back ends notify ldisc of changes to echo/edit settings by giving ldisc_send(ldisc,NULL,0,0) a special meaning, instead of by having a separate dedicated notify function with its own prototype and parameter set. Coverity's recent observation that the two kinds of call don't even have the same requirements on the ldisc (particularly, whether ldisc->term can be NULL) makes me realise that it's really high time I separated the two conceptually different operations into actually different functions. While I'm here, I've renamed the confusing ldisc_update() function which that special operation ends up feeding to, because it's not actually a function applying to an ldisc - it applies to a front end. So ldisc_send(ldisc,NULL,0,0) is now ldisc_echoedit_update(ldisc), and that in turn figures out the current echo/edit settings before passing them on to frontend_echoedit_update(). I think that should be clearer.
2014-11-22 16:12:47 +00:00
ldisc_echoedit_update(inst->ldisc);
Add some missing null checks for inst->ldisc, which were causing 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]
2013-07-11 17:24:20 +00:00
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
/* Pass new config data to the terminal */
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
term_reconfig(inst->term, inst->conf);
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
setup_clipboards(inst, inst->term, inst->conf);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
/* Pass new config data to the back end */
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (inst->backend)
backend_reconfig(inst->backend, inst->conf);
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cache_conf_values(inst);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
need_size = false;
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
/*
* If the scrollbar needs to be shown, hidden, or moved
* from one end to the other of the window, do so now.
*/
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(oldconf, CONF_scrollbar) !=
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_get_bool(newconf, CONF_scrollbar)) {
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
show_scrollbar(inst, conf_get_bool(newconf, CONF_scrollbar));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
need_size = true;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
}
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(oldconf, CONF_scrollbar_on_left) !=
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_get_bool(newconf, CONF_scrollbar_on_left)) {
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
gtk_box_reorder_child(inst->hbox, inst->sbar,
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
conf_get_bool(newconf, CONF_scrollbar_on_left)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
? 0 : 1);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
}
/*
* Redo the whole tangled fonts and Unicode mess if
* necessary.
*/
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
if (strcmp(conf_get_fontspec(oldconf, CONF_font)->name,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_get_fontspec(newconf, CONF_font)->name) ||
strcmp(conf_get_fontspec(oldconf, CONF_boldfont)->name,
conf_get_fontspec(newconf, CONF_boldfont)->name) ||
strcmp(conf_get_fontspec(oldconf, CONF_widefont)->name,
conf_get_fontspec(newconf, CONF_widefont)->name) ||
strcmp(conf_get_fontspec(oldconf, CONF_wideboldfont)->name,
conf_get_fontspec(newconf, CONF_wideboldfont)->name) ||
strcmp(conf_get_str(oldconf, CONF_line_codepage),
conf_get_str(newconf, CONF_line_codepage)) ||
conf_get_bool(oldconf, CONF_utf8_override) !=
conf_get_bool(newconf, CONF_utf8_override) ||
conf_get_int(oldconf, CONF_vtmode) !=
conf_get_int(newconf, CONF_vtmode) ||
conf_get_bool(oldconf, CONF_shadowbold) !=
conf_get_bool(newconf, CONF_shadowbold) ||
conf_get_int(oldconf, CONF_shadowboldoffset) !=
conf_get_int(newconf, CONF_shadowboldoffset)) {
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
char *errmsg = setup_fonts_ucs(inst);
if (errmsg) {
char *msgboxtext =
dupprintf("Could not change fonts in terminal window: %s\n",
errmsg);
Make the GTK font setup error box non-modal. That was the last (in fact, the only) call to the modal version of message_box() outside gtkdlg.c, so I can remove it from the header file.
2017-11-26 17:07:47 +00:00
create_message_box(
inst->window, "Font setup error", msgboxtext,
string_width("Could not change fonts in terminal window:"),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
false, &buttons_ok, trivial_post_dialog_fn, NULL);
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 10:46:07 +00:00
sfree(msgboxtext);
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
sfree(errmsg);
} else {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
need_size = true;
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
}
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
/*
* Resize the window.
*/
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
if (conf_get_int(oldconf, CONF_width) !=
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_get_int(newconf, CONF_width) ||
conf_get_int(oldconf, CONF_height) !=
conf_get_int(newconf, CONF_height) ||
conf_get_int(oldconf, CONF_window_border) !=
conf_get_int(newconf, CONF_window_border) ||
need_size) {
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
set_geom_hints(inst);
GTK: don't try to change font size in mid-window-resize. If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
2022-05-12 18:38:45 +00:00
request_resize_internal(inst, false,
conf_get_int(newconf, CONF_width),
conf_get_int(newconf, CONF_height));
Mid-session reconfiguration of scrollback was failing (in Unix) except when width or height had _also_ been changed. Fixed. [originally from svn r3108]
2003-04-12 10:44:14 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* The above will have caused a call to term_size() for
* us if it happened. If the user has fiddled with only
* the scrollback size, the above will not have
* happened and we will need an explicit term_size()
* here.
*/
if (conf_get_int(oldconf, CONF_savelines) !=
conf_get_int(newconf, CONF_savelines))
term_size(inst->term, inst->term->rows, inst->term->cols,
conf_get_int(newconf, CONF_savelines));
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
term_invalidate(inst->term);
Debian bug #193013 points out that the (default-)one-pixel border is not redrawn when the window background colour is reconfigured mid- session. In addition, the Official Window Background is not reset, meaning that opaque resizes etc will flicker in the old background colour. This checkin should fix both. [originally from svn r3190]
2003-05-13 18:14:14 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* We do an explicit full redraw here to ensure the window
* border has been redrawn as well as the text area.
*/
gtk_widget_queue_draw(inst->area);
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_free(oldconf);
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_free(newconf);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
}
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void change_font_size(GtkFrontend *inst, int increment)
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
{
static const int conf_keys[lenof(inst->fonts)] = {
CONF_font, CONF_boldfont, CONF_widefont, CONF_wideboldfont,
};
FontSpec *oldfonts[lenof(inst->fonts)];
FontSpec *newfonts[lenof(inst->fonts)];
char *errmsg = NULL;
int i;
for (i = 0; i < lenof(newfonts); i++)
oldfonts[i] = newfonts[i] = NULL;
for (i = 0; i < lenof(inst->fonts); i++) {
if (inst->fonts[i]) {
char *newname = unifont_size_increment(inst->fonts[i], increment);
if (!newname)
goto cleanup;
newfonts[i] = fontspec_new(newname);
sfree(newname);
}
}
for (i = 0; i < lenof(newfonts); i++) {
if (newfonts[i]) {
oldfonts[i] = fontspec_copy(
conf_get_fontspec(inst->conf, conf_keys[i]));
conf_set_fontspec(inst->conf, conf_keys[i], newfonts[i]);
}
}
errmsg = setup_fonts_ucs(inst);
if (errmsg)
goto cleanup;
/* Success, so suppress putting everything back */
for (i = 0; i < lenof(newfonts); i++) {
if (oldfonts[i]) {
fontspec_free(oldfonts[i]);
oldfonts[i] = NULL;
}
}
set_geom_hints(inst);
GTK: don't try to change font size in mid-window-resize. If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
2022-05-12 18:38:45 +00:00
request_resize_internal(inst, false, conf_get_int(inst->conf, CONF_width),
conf_get_int(inst->conf, CONF_height));
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 13:53:42 +00:00
term_invalidate(inst->term);
gtk_widget_queue_draw(inst->area);
cleanup:
for (i = 0; i < lenof(oldfonts); i++) {
if (oldfonts[i]) {
conf_set_fontspec(inst->conf, conf_keys[i], oldfonts[i]);
fontspec_free(oldfonts[i]);
}
if (newfonts[i])
fontspec_free(newfonts[i]);
}
sfree(errmsg);
}
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
void dup_session_menuitem(GtkMenuItem *item, gpointer gdata)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)gdata;
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
Divide the whole of gtkwin.c into three parts. 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.
2016-03-22 21:24:30 +00:00
launch_duplicate_session(inst->conf);
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
}
void new_session_menuitem(GtkMenuItem *item, gpointer data)
{
Divide the whole of gtkwin.c into three parts. 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.
2016-03-22 21:24:30 +00:00
launch_new_session();
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
}
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
void restart_session_menuitem(GtkMenuItem *item, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!inst->backend) {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
logevent(inst->logctx, "----- Session restarted -----");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_pwron(inst->term, false);
start_backend(inst);
inst->exited = false;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
}
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
void saved_session_menuitem(GtkMenuItem *item, gpointer data)
{
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
char *str = (char *)g_object_get_data(G_OBJECT(item), "user-data");
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
Divide the whole of gtkwin.c into three parts. 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.
2016-03-22 21:24:30 +00:00
launch_saved_session(str);
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
}
void saved_session_freedata(GtkMenuItem *item, gpointer data)
{
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
char *str = (char *)g_object_get_data(G_OBJECT(item), "user-data");
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
sfree(str);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
void app_menu_action(GtkFrontend *frontend, enum MenuAction action)
Fill in some more of the OS X menu bar. This still isn't complete: I also need to add the variable collections of things like mid-session special commands and saved session names, and also I need to try to grey out menu items when they're not applicable. But it's a start.
2017-12-18 11:46:48 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)frontend;
Fill in some more of the OS X menu bar. This still isn't complete: I also need to add the variable collections of things like mid-session special commands and saved session names, and also I need to try to grey out menu items when they're not applicable. But it's a start.
2017-12-18 11:46:48 +00:00
switch (action) {
case MA_COPY:
copy_clipboard_menuitem(NULL, inst);
break;
case MA_PASTE:
paste_clipboard_menuitem(NULL, inst);
break;
case MA_COPY_ALL:
copy_all_menuitem(NULL, inst);
break;
case MA_DUPLICATE_SESSION:
dup_session_menuitem(NULL, inst);
break;
case MA_RESTART_SESSION:
restart_session_menuitem(NULL, inst);
break;
case MA_CHANGE_SETTINGS:
change_settings_menuitem(NULL, inst);
break;
case MA_CLEAR_SCROLLBACK:
clear_scrollback_menuitem(NULL, inst);
break;
case MA_RESET_TERMINAL:
reset_terminal_menuitem(NULL, inst);
break;
case MA_EVENT_LOG:
event_log_menuitem(NULL, inst);
break;
}
}
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
static void update_savedsess_menu(GtkMenuItem *menuitem, gpointer data)
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = (GtkFrontend *)data;
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
struct sesslist sesslist;
int i;
gtk_container_foreach(GTK_CONTAINER(inst->sessionsmenu),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(GtkCallback)gtk_widget_destroy, NULL);
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
get_sesslist(&sesslist, true);
If there are no saved sessions, put a grayed "(No sessions)" entry on the saved sessions submenu of the terminal window context menu (as Pageant does), rather than an empty menu (which often renders poorly). [originally from svn r8648]
2009-09-13 23:29:11 +00:00
/* skip sesslist.sessions[0] == Default Settings */
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
for (i = 1; i < sesslist.nsessions; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *menuitem =
gtk_menu_item_new_with_label(sesslist.sessions[i]);
gtk_container_add(GTK_CONTAINER(inst->sessionsmenu), menuitem);
gtk_widget_show(menuitem);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set_data(G_OBJECT(menuitem), "user-data",
dupstr(sesslist.sessions[i]));
g_signal_connect(G_OBJECT(menuitem), "activate",
G_CALLBACK(saved_session_menuitem),
inst);
g_signal_connect(G_OBJECT(menuitem), "destroy",
G_CALLBACK(saved_session_freedata),
inst);
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
}
If there are no saved sessions, put a grayed "(No sessions)" entry on the saved sessions submenu of the terminal window context menu (as Pageant does), rather than an empty menu (which often renders poorly). [originally from svn r8648]
2009-09-13 23:29:11 +00:00
if (sesslist.nsessions <= 1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *menuitem =
gtk_menu_item_new_with_label("(No sessions)");
gtk_widget_set_sensitive(menuitem, false);
gtk_container_add(GTK_CONTAINER(inst->sessionsmenu), menuitem);
gtk_widget_show(menuitem);
If there are no saved sessions, put a grayed "(No sessions)" entry on the saved sessions submenu of the terminal window context menu (as Pageant does), rather than an empty menu (which often renders poorly). [originally from svn r8648]
2009-09-13 23:29:11 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
get_sesslist(&sesslist, false); /* free up */
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
}
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
void set_window_icon(GtkWidget *window, const char *const *const *icon,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int n_icon)
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
{
#if GTK_CHECK_VERSION(2,0,0)
GList *iconlist;
int n;
Use gtk_window_set_icon() where available. GTK is deprecating the use of gdk_window_set_icon(), in favour of a method that doesn't have to drop down to the GDK level at all (and also doesn't use a pixmap). No reason not to use that instead.
2015-08-16 08:41:10 +00:00
#else
GdkPixmap *iconpm;
GdkBitmap *iconmask;
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
#endif
if (!n_icon)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
gtk_widget_realize(window);
Use gtk_window_set_icon() where available. GTK is deprecating the use of gdk_window_set_icon(), in favour of a method that doesn't have to drop down to the GDK level at all (and also doesn't use a pixmap). No reason not to use that instead.
2015-08-16 08:41:10 +00:00
#if GTK_CHECK_VERSION(2,0,0)
gtk_window_set_icon(GTK_WINDOW(window),
gdk_pixbuf_new_from_xpm_data((const gchar **)icon[0]));
#else
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
iconpm = gdk_pixmap_create_from_xpm_d(gtk_widget_get_window(window),
&iconmask, NULL, (gchar **)icon[0]);
gdk_window_set_icon(gtk_widget_get_window(window), NULL, iconpm, iconmask);
Use gtk_window_set_icon() where available. GTK is deprecating the use of gdk_window_set_icon(), in favour of a method that doesn't have to drop down to the GDK level at all (and also doesn't use a pixmap). No reason not to use that instead.
2015-08-16 08:41:10 +00:00
#endif
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
#if GTK_CHECK_VERSION(2,0,0)
iconlist = NULL;
for (n = 0; n < n_icon; n++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
iconlist =
g_list_append(iconlist,
gdk_pixbuf_new_from_xpm_data((const gchar **)
icon[n]));
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
}
Use gtk_window_set_icon() where available. GTK is deprecating the use of gdk_window_set_icon(), in favour of a method that doesn't have to drop down to the GDK level at all (and also doesn't use a pixmap). No reason not to use that instead.
2015-08-16 08:41:10 +00:00
gtk_window_set_icon_list(GTK_WINDOW(window), iconlist);
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
#endif
}
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
static void free_special_cmd(gpointer data) { sfree(data); }
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void gtk_seat_update_specials_menu(Seat *seat)
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
const SessionSpecial *specials;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (inst->backend)
specials = backend_get_specials(inst->backend);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
specials = NULL;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
Support the SSH-2 mechanism for sending signals to a running session. Neither of the SSH servers I conveniently have access to (Debian stable OpenSSH -- 3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel requests look fine to me in the packet log. I've included all the signals explicitly defined by draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu of the specials menu; there's therefore been some minor upheaval to support such submenus. [originally from svn r4652]
2004-10-17 21:22:22 +00:00
/* I believe this disposes of submenus too. */
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_container_foreach(GTK_CONTAINER(inst->specialsmenu),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(GtkCallback)gtk_widget_destroy, NULL);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
if (specials) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
GtkWidget *menu = inst->specialsmenu;
/* A lame "stack" for submenus that will do for now. */
GtkWidget *saved_menu = NULL;
int nesting = 1;
for (i = 0; nesting > 0; i++) {
GtkWidget *menuitem = NULL;
switch (specials[i].code) {
case SS_SUBMENU:
assert (nesting < 2);
saved_menu = menu; /* XXX lame stacking */
menu = gtk_menu_new();
menuitem = gtk_menu_item_new_with_label(specials[i].name);
gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuitem), menu);
gtk_container_add(GTK_CONTAINER(saved_menu), menuitem);
gtk_widget_show(menuitem);
menuitem = NULL;
nesting++;
break;
case SS_EXITMENU:
nesting--;
if (nesting) {
menu = saved_menu; /* XXX lame stacking */
saved_menu = NULL;
}
break;
case SS_SEP:
menuitem = gtk_menu_item_new();
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
default: {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
menuitem = gtk_menu_item_new_with_label(specials[i].name);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
SessionSpecial *sc = snew(SessionSpecial);
*sc = specials[i]; /* structure copy */
g_object_set_data_full(G_OBJECT(menuitem), "user-data",
sc, free_special_cmd);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(menuitem), "activate",
G_CALLBACK(special_menuitem), inst);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
if (menuitem) {
gtk_container_add(GTK_CONTAINER(menu), menuitem);
gtk_widget_show(menuitem);
}
}
gtk_widget_show(inst->specialsitem1);
gtk_widget_show(inst->specialsitem2);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_hide(inst->specialsitem1);
gtk_widget_hide(inst->specialsitem2);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void start_backend(GtkFrontend *inst)
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 14:32:06 +00:00
{
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
const struct BackendVtable *vt;
Make the backend_init error message dynamic. (NFC) Now, instead of a 'const char *' in the static data segment, error messages returned from backend setup are dynamically allocated and freed by the caller. This will allow me to make the messages much more specific (including errno values and the like). However, this commit is pure refactoring: I've _just_ changed the allocation policy, and left all the messages alone.
2020-04-18 12:28:33 +00:00
char *error, *realhost;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
Fix command-line password handling in Restart Session. When the user provides a password on the PuTTY command line, via -pw or -pwfile, the flag 'tried_once' inside cmdline_get_passwd_input() is intended to arrange that we only try sending that password once, and after we've sent it, we don't try again. But this plays badly with the 'Restart Session' operation. If the connection is lost and then restarted at user request, we _do_ want to send that password again! So this commit moves that static variable out into a small state structure held by the client of cmdline_get_passwd_input. Each client can decide how to manage that state itself. Clients that support 'Restart Session' - i.e. just GUI PuTTY itself - will initialise the state at the same time as instantiating the backend, so that every time the session is restarted, we return to (correctly) believing that we _haven't_ yet tried the password provided on the command line. But clients that don't support 'Restart Session' - i.e. Plink and file transfer tools - can do the same thing that cmdline.c was doing before: just keep the state in a static variable. This also means that the GUI login tools will now retain the command-line password in memory, whereas previously they'd have wiped it out once it was used. But the other tools will still wipe and free the password, because I've also added a 'bool restartable' flag to cmdline_get_passwd_input to let it know when it _is_ allowed to do that. In the GUI tools, I don't see any way to get round that, because if the session is restarted you _have_ to still have the password to use again. (And you can't infer that that will never happen from the CONF_close_on_exit setting, because that too could be changed in mid-session.) On the other hand, I think it's not all that worrying, because the use of either -pw or -pwfile means that a persistent copy of your password is *already* stored somewhere, so another one isn't too big a stretch. (Due to the change of -pw policy in 0.77, the effect of this bug was that an attempt to reconnect in a session set up this way would lead to "Configured password was not accepted". In 0.76, the failure mode was different: PuTTY would interactively prompt for the password, having wiped it out of memory after it was used the first time round.)
2022-05-18 12:04:56 +00:00
inst->cmdline_get_passwd_state = cmdline_get_passwd_input_state_new;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
vt = select_backend(inst->conf);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
Re-enable trust sigils on Restart Session. In my eagerness to make sure we didn't _accidentally_ change the seat's trust status back to trusted at any point, I forgot to do it on purpose if a second SSH login phase is legitimately run in the same terminal after the first session has ended.
2019-03-20 15:07:32 +00:00
seat_set_trust_status(&inst->seat, true);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
error = backend_init(vt, &inst->seat, &inst->backend,
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
inst->logctx, inst->conf,
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
conf_get_str(inst->conf, CONF_host),
conf_get_int(inst->conf, CONF_port),
&realhost,
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
conf_get_bool(inst->conf, CONF_tcp_nodelay),
conf_get_bool(inst->conf, CONF_tcp_keepalives));
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
if (error) {
Special backend init error handling for pterm. Fixes a cosmetic issue where the new ConPTY error added in 4ae8b742ab had an ugly "Unable to open connection to". (Arguably this ought to test a backend property rather than cmdline_tooltype.)
2022-05-24 12:32:55 +00:00
if (cmdline_tooltype & TOOLTYPE_NONNETWORK) {
/* Special case for pterm. */
seat_connection_fatal(&inst->seat,
"Unable to open terminal:\n%s",
error);
} else {
seat_connection_fatal(&inst->seat,
"Unable to open connection to %s:\n%s",
conf_dest(inst->conf), error);
}
Make the backend_init error message dynamic. (NFC) Now, instead of a 'const char *' in the static data segment, error messages returned from backend setup are dynamically allocated and freed by the caller. This will allow me to make the messages much more specific (including errno values and the like). However, this commit is pure refactoring: I've _just_ changed the allocation policy, and left all the messages alone.
2020-04-18 12:28:33 +00:00
sfree(error);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->exited = true;
GTK: handle synchronous connection-setup failures sensibly. This was one of a handful of remaining places in gtkwin.c where exit() is called incautiously. Of course, a failure to set up one SSH connection should only be fatal to that connection, not the whole process, so really we should be feeding into the connection_fatal system.
2017-11-27 19:32:39 +00:00
return;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
Move all window-title management into Terminal. Previously, window title management happened in a bipartisan sort of way: front ends would choose their initial window title once they knew what host name they were connecting to, but then Terminal would override that later if the server set the window title by escape sequences. Now it's all done the same way round: the Terminal object is always where titles are invented, and they only propagate in one direction, from the Terminal to the TermWin. This allows us to avoid duplicating in multiple front ends the logic for what the initial window title should be. The frontend just has to make one initial call to term_setup_window_titles, to tell the terminal what hostname should go in the default title (if the Conf doesn't override even that). Thereafter, all it has to do is respond to the TermWin title-setting methods. Similarly, the logic that handles window-title changes as a result of the Change Settings dialog is also centralised into terminal.c. This involved introducing an extra term_pre_reconfig() call that each frontend can call to modify the Conf that will be used for the GUI configurer; that's where the code now lives that copies the current window title into there. (This also means that GTK PuTTY now behaves consistently with Windows PuTTY on that point; GTK's previous behaviour was less well thought out.) It also means there's no longer any need for Terminal to talk to the front end when a remote query wants to _find out_ the window title: the Terminal knows the answer already. So TermWin's get_title method can go.
2021-02-07 19:59:20 +00:00
term_setup_window_titles(inst->term, realhost);
Fix minor memory leak. [originally from svn r6611]
2006-03-14 22:01:27 +00:00
sfree(realhost);
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
term_provide_backend(inst->term, inst->backend);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
inst->ldisc = ldisc_create(inst->conf, inst->term, inst->backend,
&inst->seat);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_widget_set_sensitive(inst->restartitem, false);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-05 21:46:53 +00:00
static void get_monitor_geometry(GtkWidget *widget, GdkRectangle *geometry)
{
#if GTK_CHECK_VERSION(3,4,0)
GdkDisplay *display = gtk_widget_get_display(widget);
GdkWindow *gdkwindow = gtk_widget_get_window(widget);
# if GTK_CHECK_VERSION(3,22,0)
GdkMonitor *monitor;
if (gdkwindow)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
monitor = gdk_display_get_monitor_at_window(display, gdkwindow);
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-05 21:46:53 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
monitor = gdk_display_get_monitor(display, 0);
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-05 21:46:53 +00:00
gdk_monitor_get_geometry(monitor, geometry);
# else
GdkScreen *screen = gdk_display_get_default_screen(display);
gint monitor_num = gdk_screen_get_monitor_at_window(screen, gdkwindow);
gdk_screen_get_monitor_geometry(screen, monitor_num, geometry);
# endif
#else
geometry->x = geometry->y = 0;
geometry->width = gdk_screen_width();
geometry->height = gdk_screen_height();
#endif
}
Make the current code compile again under GTK1. Apparently I haven't tested this compile mode in a while: I had a couple of compile errors due to new code not properly #ifdeffed (the true-colour mode has to be effectively disabled in the palette-based GTK1 graphics model) and one for an unused static function (get_monitor_geometry is only used in GTK2 and above, and with -Werror that means I mustn't even _define_ it in GTK1). With these changes, I still didn't get a clean compile unless I also configured CFLAGS=-std=gnu89, due to the GTK1 headers having an outdated set of ifdefs to figure out the compiler's semantics of 'inline'. (They seem to expect old-style gcc, which inconveniently treats 'inline' and 'extern inline' more or less the opposite way round from the version standardised by C99.)
2017-11-26 08:56:16 +00:00
#endif
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-05 21:46:53 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static const TermWinVtable gtk_termwin_vt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.setup_draw_ctx = gtkwin_setup_draw_ctx,
.draw_text = gtkwin_draw_text,
.draw_cursor = gtkwin_draw_cursor,
.draw_trust_sigil = gtkwin_draw_trust_sigil,
.char_width = gtkwin_char_width,
.free_draw_ctx = gtkwin_free_draw_ctx,
.set_cursor_pos = gtkwin_set_cursor_pos,
.set_raw_mouse_mode = gtkwin_set_raw_mouse_mode,
Decouple frontend's raw mouse mode from pointer shape. This paves the way for a followup commit that will make them happen at slightly different times.
2021-02-07 19:59:21 +00:00
.set_raw_mouse_mode_pointer = gtkwin_set_raw_mouse_mode_pointer,
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.set_scrollbar = gtkwin_set_scrollbar,
.bell = gtkwin_bell,
.clip_write = gtkwin_clip_write,
.clip_request_paste = gtkwin_clip_request_paste,
.refresh = gtkwin_refresh,
.request_resize = gtkwin_request_resize,
.set_title = gtkwin_set_title,
.set_icon_title = gtkwin_set_icon_title,
.set_minimised = gtkwin_set_minimised,
.set_maximised = gtkwin_set_maximised,
.move = gtkwin_move,
.set_zorder = gtkwin_set_zorder,
.palette_set = gtkwin_palette_set,
Centralise palette setup into terminal.c. Now terminal.c makes nearly all the decisions about what the colour palette should actually contain: it does the job of reading the GUI-configurable colours out of Conf, and also the job of making up the rest of the xterm-256 palette. The only exception is that TermWin can provide a method to override some of the default colours, which on Windows is used to implement the 'Use system colours' config option. This saves code overall, partly because the front ends don't have to be able to send palette data back to the Terminal any more (the Terminal keeps the master copy and can answer palette-query escape sequences from its own knowledge), and also because now there's only one copy of the xterm-256 palette setup code (previously gtkwin.c and window.c each had their own version of it). In this rewrite, I've also introduced a multi-layered storage system for the palette data in Terminal. One layer contains the palette information derived from Conf; the next contains platform overrides (currently just Windows's 'Use system colours'); the last one contains overrides set by escape sequences in the middle of the session. The topmost two layers can each _conditionally_ override the ones below. As a result, if a server-side application manually resets (say) the default fg and bg colours in mid-session to something that works well in a particular application, those changes won't be wiped out by a change in the Windows system colours or the Conf, which they would have been before. Instead, changes in Conf or the system colours alter the lower layers of the structure, but then when palette_rebuild is called, the upper layer continues to override them, until a palette reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer changes. This seems like a more consistent strategy, in that the same set of configuration settings will produce the same end result regardless of what order they were applied in. The palette-related methods in TermWin have had a total rework. palette_get and palette_reset are both gone; palette_set can now set a contiguous range of colours in one go; and the new palette_get_overrides replaces window.c's old systopalette().
2021-02-07 19:59:21 +00:00
.palette_get_overrides = gtkwin_palette_get_overrides,
Proper buffer management between terminal and backend. The return value of term_data() is used as the return value from the GUI-terminal versions of the Seat output method, which means backends will take it to be the amount of standard-output data currently buffered, and exert back-pressure on the remote peer if it gets too big (e.g. by ceasing to extend the window in that particular SSH-2 channel). Historically, as a comment in term_data() explained, we always just returned 0 from that function, on the basis that we were processing all the terminal data through our terminal emulation code immediately, and never retained any of it in the buffer at all. If the terminal emulation code were to start running slowly, then it would slow down the _whole_ PuTTY system, due to single-threadedness, and back-pressure of a sort would be exerted on the remote by it simply failing to get round to reading from the network socket. But by the time we got back to the top level of term_data(), we'd have finished reading all the data we had, so it was still appropriate to return 0. That comment is still correct if you're thinking about the limiting factor on terminal data processing being the CPU usage in term_out(). But now that's no longer the whole story, because sometimes we leave data in term->inbuf without having processed it: during drag-selects in the terminal window, and (just introduced) while waiting for the response to a pending window resize request. For both those reasons, we _don't_ always have a buffer size of zero when we return from term_data(). So now that hole in our buffer size management is filled in: term_data() returns the true size of the remaining unprocessed terminal output, so that back-pressure will be exerted if the terminal is currently not consuming it. And when processing resumes and we start to clear our backlog, we call backend_unthrottle to let the backend know it can relax the back-pressure if necessary.
2021-12-12 10:57:23 +00:00
.unthrottle = gtkwin_unthrottle,
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
};
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
void new_session_window(Conf *conf, const char *geometry_string)
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
GtkFrontend *inst;
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 14:32:06 +00:00
Unix PuTTY: add missing call to prepare_session. Now 'putty user@host' will do what you wanted on Unix the same way it always has on Windows. (Thanks to Geoff Winkless for pointing out this inconsistency. I've redone his actual patch my way, but he should still be credited for the inspiration!)
2017-12-03 14:38:55 +00:00
prepare_session(conf);
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
/*
* Create an instance structure and initialise to zeroes
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst = snew(GtkFrontend);
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
memset(inst, 0, sizeof(*inst));
Better protection against stale clipboard_data_instances. I had a segfault on OS X today at Pterm.app shutdown. I wasn't able to reproduce it in a debugger, but the cause seemed to be that clipboard_clear called term_deselect (this was from before the patch series that renamed that function) when inst->term was already NULL. This must be because a clipboard_data_instance outlived its associated inst->term, and quite likely its associated inst as well. But we can't free those structures when a gui_data is freed, because GTK callbacks will still depend on them; so instead we must have each gui_data keep a list of active cdis pointing at it, and then at destruction time, walk along the list nulling out each one's pointer to part of itself.
2017-12-17 20:12:52 +00:00
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
inst->cdi_headtail.next = inst->cdi_headtail.prev = &inst->cdi_headtail;
#endif
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
inst->alt_keycode = -1; /* this one needs _not_ to be zero */
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
inst->busy_status = BUSY_NOT;
Divide the whole of gtkwin.c into three parts. 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.
2016-03-22 21:24:30 +00:00
inst->conf = conf;
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
inst->wintitle = inst->icontitle = NULL;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
inst->drawtype = DRAWTYPE_DEFAULT;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
#if GTK_CHECK_VERSION(3,4,0)
Support horizontal scroll events in mouse tracking. Horizontal scroll events aren't generated by the traditional mouse wheel, but they can be generated by trackpad gestures, though this isn't always configured on. The cross-platform and Windows parts of this patch is due to Christopher Plewright; I added the GTK support.
2022-11-22 18:36:23 +00:00
inst->cumulative_vscroll = 0.0;
inst->cumulative_hscroll = 0.0;
Support smooth scrolling in GTK3. 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.
2015-09-25 14:11:44 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->drawing_area_setup_needed = true;
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst->termwin.vt = &gtk_termwin_vt;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
inst->seat.vt = &gtk_seat_vt;
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
inst->logpolicy.vt = &gtk_logpolicy_vt;
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
#ifndef NOT_X_WINDOWS
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
inst->disp = get_x11_display();
Divide the whole of gtkwin.c into three parts. 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.
2016-03-22 21:24:30 +00:00
if (geometry_string) {
int flags, x, y;
unsigned int w, h;
flags = XParseGeometry(geometry_string, &x, &y, &w, &h);
if (flags & WidthValue)
conf_set_int(conf, CONF_width, w);
if (flags & HeightValue)
conf_set_int(conf, CONF_height, h);
if (flags & (XValue | YValue)) {
inst->xpos = x;
inst->ypos = y;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->gotpos = true;
Divide the whole of gtkwin.c into three parts. 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.
2016-03-22 21:24:30 +00:00
inst->gravity = ((flags & XNegative ? 1 : 0) |
(flags & YNegative ? 2 : 0));
}
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
}
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
#endif
Having created and used uxsel, it actually turns out to be practically trivial to put all the pieces together and create a working prototype of Unix PuTTY! It's missing a lot of things - notably GUI request boxes for host keys and logfiles and so forth, the Event Log, mid-session reconfiguration, session loading and saving, sensible population of the character sets drop-down list and probably other fiddly little things too - but it will put up a config box and then create a GUI window containing an SSH connection to the host you specified, so it's _basically_ there. Woo! [originally from svn r3020]
2003-03-29 19:52:50 +00:00
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
if (!compound_text_atom)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
compound_text_atom = gdk_atom_intern("COMPOUND_TEXT", false);
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
if (!utf8_string_atom)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
utf8_string_atom = gdk_atom_intern("UTF8_STRING", false);
GTK1 build fixes. Looks as if I haven't retried the GTK1 build for a while, and recent GTK frontend development has broken it. The selection revamp has pointed out that GTK1 didn't have the accessor function gtk_selection_data_get_selection(), the standard GdkAtom value GDK_SELECTION_CLIPBOARD, or keysyms for alphabetic characters; and also I had an initialisation of one of my own structure fields (dp->selparams) accidentally not guarded by the same GTK-versioning ifdef that controls whether or not it was defined.
2018-03-03 18:18:54 +00:00
if (!clipboard_atom)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
clipboard_atom = gdk_atom_intern("CLIPBOARD", false);
gnome-terminal insists on receiving the selection as COMPOUND_TEXT rather than STRING, so we can now supply that too. Pasting both ways between pterm and gnome-terminal now works. [originally from svn r2038]
2002-10-13 23:48:31 +00:00
Implemented a Pango back end. GTK 2 PuTTY can now switch seamlessly back and forth between X fonts and Pango fonts, provided you're willing to type in the names of the former by hand. [originally from svn r7937]
2008-03-22 18:11:17 +00:00
inst->area = gtk_drawing_area_new();
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
gtk_widget_set_name(GTK_WIDGET(inst->area), "drawing-area");
Implemented a Pango back end. GTK 2 PuTTY can now switch seamlessly back and forth between X fonts and Pango fonts, provided you're willing to type in the names of the former by hand. [originally from svn r7937]
2008-03-22 18:11:17 +00:00
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
{
char *errmsg = setup_fonts_ucs(inst);
if (errmsg) {
GTK: fix the exit(1) response to startup-time font errors. For gtkapp-based tools that will have to stop being a program-fatal error, so I've turned it into a function called window_setup_error (which I could in principle reuse for other problems in the long and tortuous progress of new_session_window), and kept the original handling in gtkmain.c's implementation of that function while gtkapp.c does something more sensible with a message box.
2017-11-27 20:09:54 +00:00
window_setup_error(errmsg);
sfree(errmsg);
gtk_widget_destroy(inst->area);
sfree(inst);
return;
Reorganise setup_fonts_ucs so that in case of error it does nothing 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]
2013-01-13 21:59:10 +00:00
}
}
GTK: fix the exit(1) response to startup-time font errors. For gtkapp-based tools that will have to stop being a program-fatal error, so I've turned it into a function called window_setup_error (which I could in principle reuse for other problems in the long and tortuous progress of new_session_window), and kept the original handling in gtkmain.c's implementation of that function while gtkapp.c does something more sensible with a message box.
2017-11-27 20:09:54 +00:00
#if GTK_CHECK_VERSION(2,0,0)
inst->imc = gtk_im_multicontext_new();
#endif
Delegate GTK window creation to gtkmain.c. 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.
2016-03-23 22:03:46 +00:00
inst->window = make_gtk_toplevel_window(inst);
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-05 21:45:04 +00:00
gtk_widget_set_name(GTK_WIDGET(inst->window), "top-level");
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
{
const char *winclass = conf_get_str(inst->conf, CONF_winclass);
Replace deprecated gtk_window_set_wmclass with raw Xlib. Calling gtk_widget_realize to enforce the existence of an underlying GdkWindow, followed by gdk_window_ensure_native to enforce an underlying X window in turn, allows me to get hold of an X window id on which I can call the Xlib function for setting WM_CLASS, still before the window is mapped. With this change, plus Colin's preceding patches, the whole code base _actually_ compiles and links against GTK 3.22 without any deprecation warnings. (My claim in commit 8ce237234 that it previously did appears to have been completely wrong - my guess is that I'd forgotten to 'make clean' before testing against 3.22 and so some source files had already been compiled against earlier GTK headers.)
2017-03-07 22:57:42 +00:00
if (*winclass) {
#if GTK_CHECK_VERSION(3,22,0)
#ifndef NOT_X_WINDOWS
GdkWindow *gdkwin;
gtk_widget_realize(GTK_WIDGET(inst->window));
gdkwin = gtk_widget_get_window(GTK_WIDGET(inst->window));
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
if (inst->disp && gdk_window_ensure_native(gdkwin)) {
Replace deprecated gtk_window_set_wmclass with raw Xlib. Calling gtk_widget_realize to enforce the existence of an underlying GdkWindow, followed by gdk_window_ensure_native to enforce an underlying X window in turn, allows me to get hold of an X window id on which I can call the Xlib function for setting WM_CLASS, still before the window is mapped. With this change, plus Colin's preceding patches, the whole code base _actually_ compiles and links against GTK 3.22 without any deprecation warnings. (My claim in commit 8ce237234 that it previously did appears to have been completely wrong - my guess is that I'd forgotten to 'make clean' before testing against 3.22 and so some source files had already been compiled against earlier GTK headers.)
2017-03-07 22:57:42 +00:00
XClassHint *xch = XAllocClassHint();
xch->res_name = (char *)winclass;
xch->res_class = (char *)winclass;
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
XSetClassHint(inst->disp, GDK_WINDOW_XID(gdkwin), xch);
Replace deprecated gtk_window_set_wmclass with raw Xlib. Calling gtk_widget_realize to enforce the existence of an underlying GdkWindow, followed by gdk_window_ensure_native to enforce an underlying X window in turn, allows me to get hold of an X window id on which I can call the Xlib function for setting WM_CLASS, still before the window is mapped. With this change, plus Colin's preceding patches, the whole code base _actually_ compiles and links against GTK 3.22 without any deprecation warnings. (My claim in commit 8ce237234 that it previously did appears to have been completely wrong - my guess is that I'd forgotten to 'make clean' before testing against 3.22 and so some source files had already been compiled against earlier GTK headers.)
2017-03-07 22:57:42 +00:00
XFree(xch);
}
#endif
/*
* If we do have NOT_X_WINDOWS set, then we don't have any
* function in GTK 3.22 equivalent to the above. But then,
* surely in that situation the deprecated
* gtk_window_set_wmclass wouldn't have done anything
* meaningful in previous GTKs either.
*/
#else
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
gtk_window_set_wmclass(GTK_WINDOW(inst->window),
winclass, winclass);
Replace deprecated gtk_window_set_wmclass with raw Xlib. Calling gtk_widget_realize to enforce the existence of an underlying GdkWindow, followed by gdk_window_ensure_native to enforce an underlying X window in turn, allows me to get hold of an X window id on which I can call the Xlib function for setting WM_CLASS, still before the window is mapped. With this change, plus Colin's preceding patches, the whole code base _actually_ compiles and links against GTK 3.22 without any deprecation warnings. (My claim in commit 8ce237234 that it previously did appears to have been completely wrong - my guess is that I'd forgotten to 'make clean' before testing against 3.22 and so some source files had already been compiled against earlier GTK headers.)
2017-03-07 22:57:42 +00:00
#endif
}
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
}
Window title configurability: -T to set it from the command line, support for the xterm escape sequences to set it, and support for the xterm escape sequence to query it. [originally from svn r2040]
2002-10-14 00:05:37 +00:00
GTK: stop using geometry hints when not on X11. While re-testing on Wayland after all this churn of the window resizing code, I discovered that the window constantly came out a few pixels too small, losing a character cell in width and height. This stopped happening once I experimentally stopped setting geometry hints. Source-diving in GTK, it turns out that this is because the GDK Wayland backend is applying the geometry hints to the size of the window including 'margins', which are a very large extra space around a window beyond even the visible 'non-client-area' furniture like the title bar. And I have no idea how you find out the size of those margins, so I can't allow for them in the geometry hints. I also noticed that gtk_window_set_geometry_hints is removed in GTK 4, which suggests that GTK upstream are probably not interested in fiddling with them until they work more usefully (even if they would agree with me that this is a bug in the first place, which I have no idea). A simpler workaround is to avoid setting geometry hints at all on any GDK backend other than X11. So, that's what this commit does. On Wayland (or other backends), the window can now be resized a pixel at a time, and if its size doesn't work out to a whole number of character cells, then you just get some dead space at the edges. Not especially nice, but better than the alternatives I can see. One other job the geometry hints were doing was to forbid resizing if the backend sets the BACKEND_RESIZE_FORBIDDEN flag (which SUPDUP does). That's now done at window creation time, via gtk_window_set_resizable.
2021-12-20 11:06:57 +00:00
#if GTK_CHECK_VERSION(2,0,0)
{
const BackendVtable *vt = select_backend(inst->conf);
if (vt && vt->flags & BACKEND_RESIZE_FORBIDDEN)
gtk_window_set_resizable(GTK_WINDOW(inst->window), false);
}
#endif
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
inst->width = conf_get_int(inst->conf, CONF_width);
inst->height = conf_get_int(inst->conf, CONF_height);
cache_conf_values(inst);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
Initial support for clipboard on OS X. 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.
2015-09-02 20:37:33 +00:00
init_clipboard(inst);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
inst->sbar_adjust = GTK_ADJUSTMENT(gtk_adjustment_new(0,0,0,0,0,0));
inst->sbar = gtk_vscrollbar_new(inst->sbar_adjust);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->hbox = GTK_BOX(gtk_hbox_new(false, 0));
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 18:00:50 +00:00
/*
* We always create the scrollbar; it remains invisible if
* unwanted, so we can pop it up quickly if it suddenly becomes
* desirable.
*/
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(inst->conf, CONF_scrollbar_on_left))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_box_pack_start(inst->hbox, inst->sbar, false, false, 0);
gtk_box_pack_start(inst->hbox, inst->area, true, true, 0);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(inst->conf, CONF_scrollbar_on_left))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_box_pack_start(inst->hbox, inst->sbar, false, false, 0);
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 09:54:36 +00:00
Window title configurability: -T to set it from the command line, support for the xterm escape sequences to set it, and support for the xterm escape sequence to query it. [originally from svn r2040]
2002-10-14 00:05:37 +00:00
gtk_container_add(GTK_CONTAINER(inst->window), GTK_WIDGET(inst->hbox));
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
While writing gtkdlg.c I learned how to specify a window's initial position in GTK, so I can now implement the other half of -geometry which I'd previously believed to be impossible in GTK. It's still not perfect, because GTK apparently provides no way for us to get hold of the X reparent event in order to support negative geometries in a manner which takes account of the WM borders; but for positive position it's at least an improvement on the previous version! [originally from svn r3078]
2003-04-08 13:49:12 +00:00
gtk_widget_show(inst->area);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
show_scrollbar(inst, conf_get_bool(inst->conf, CONF_scrollbar));
While writing gtkdlg.c I learned how to specify a window's initial position in GTK, so I can now implement the other half of -geometry which I'd previously believed to be impossible in GTK. It's still not perfect, because GTK apparently provides no way for us to get hold of the X reparent event in order to support negative geometries in a manner which takes account of the WM borders; but for positive position it's at least an improvement on the previous version! [originally from svn r3078]
2003-04-08 13:49:12 +00:00
gtk_widget_show(GTK_WIDGET(inst->hbox));
Account for GtkApplicationWindow menu bar in geometry hints. 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.
2016-04-04 10:28:34 +00:00
/*
* We must call gtk_widget_realize before setting up the geometry
* hints, so that GtkApplicationWindow will have actually created
* its menu bar (if it's going to) and hence compute_geom_hints
* can find it to take its size into account.
*/
gtk_widget_realize(inst->window);
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
set_geom_hints(inst);
#if GTK_CHECK_VERSION(3,0,0)
GTK: stop using geometry-based window sizing functions. 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.
2016-04-04 10:24:24 +00:00
{
int wp, hp;
compute_whole_window_size(inst, inst->width, inst->height, &wp, &hp);
gtk_window_set_default_size(GTK_WINDOW(inst->window), wp, hp);
}
Rework window geometry to avoid using geometry_widget. 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.
2016-03-29 12:42:54 +00:00
#else
{
int w = inst->font_width * inst->width + 2*inst->window_border;
int h = inst->font_height * inst->height + 2*inst->window_border;
#if GTK_CHECK_VERSION(2,0,0)
gtk_widget_set_size_request(inst->area, w, h);
#else
gtk_drawing_area_size(GTK_DRAWING_AREA(inst->area), w, h);
#endif
}
#endif
Switch to using gtk_window_parse_geometry in GTK 2. On GTK versions where it's available, this is a much nicer way of handling the -geometry command-line option, since not only do we get all the faffing about with gravity for free, it also automatically sets the user-position WM hints.
2015-08-08 17:22:05 +00:00
#if GTK_CHECK_VERSION(2,0,0)
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
if (inst->gotpos) {
static const GdkGravity gravities[] = {
GDK_GRAVITY_NORTH_WEST,
GDK_GRAVITY_NORTH_EAST,
GDK_GRAVITY_SOUTH_WEST,
GDK_GRAVITY_SOUTH_EAST,
};
int x = inst->xpos, y = inst->ypos;
int wp, hp;
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-05 21:46:53 +00:00
GdkRectangle monitor_geometry;
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
compute_whole_window_size(inst, inst->width, inst->height, &wp, &hp);
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-05 21:46:53 +00:00
get_monitor_geometry(GTK_WIDGET(inst->window), &monitor_geometry);
if (inst->gravity & 1) x += (monitor_geometry.width - wp);
if (inst->gravity & 2) y += (monitor_geometry.height - hp);
GTK: stop using gtk_window_parse_geometry. 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.
2016-04-04 10:27:01 +00:00
gtk_window_set_gravity(GTK_WINDOW(inst->window),
gravities[inst->gravity & 3]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_move(GTK_WINDOW(inst->window), x, y);
Switch to using gtk_window_parse_geometry in GTK 2. On GTK versions where it's available, this is a much nicer way of handling the -geometry command-line option, since not only do we get all the faffing about with gravity for free, it also automatically sets the user-position WM hints.
2015-08-08 17:22:05 +00:00
}
#else
While writing gtkdlg.c I learned how to specify a window's initial position in GTK, so I can now implement the other half of -geometry which I'd previously believed to be impossible in GTK. It's still not perfect, because GTK apparently provides no way for us to get hold of the X reparent event in order to support negative geometries in a manner which takes account of the WM borders; but for positive position it's at least an improvement on the previous version! [originally from svn r3078]
2003-04-08 13:49:12 +00:00
if (inst->gotpos) {
int x = inst->xpos, y = inst->ypos;
GtkRequisition req;
gtk_widget_size_request(GTK_WIDGET(inst->window), &req);
if (inst->gravity & 1) x += gdk_screen_width() - req.width;
if (inst->gravity & 2) y += gdk_screen_height() - req.height;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_set_position(GTK_WINDOW(inst->window), GTK_WIN_POS_NONE);
gtk_widget_set_uposition(GTK_WIDGET(inst->window), x, y);
While writing gtkdlg.c I learned how to specify a window's initial position in GTK, so I can now implement the other half of -geometry which I'd previously believed to be impossible in GTK. It's still not perfect, because GTK apparently provides no way for us to get hold of the X reparent event in order to support negative geometries in a manner which takes account of the WM borders; but for positive position it's at least an improvement on the previous version! [originally from svn r3078]
2003-04-08 13:49:12 +00:00
}
Switch to using gtk_window_parse_geometry in GTK 2. On GTK versions where it's available, this is a much nicer way of handling the -geometry command-line option, since not only do we get all the faffing about with gravity for free, it also automatically sets the user-position WM hints.
2015-08-08 17:22:05 +00:00
#endif
While writing gtkdlg.c I learned how to specify a window's initial position in GTK, so I can now implement the other half of -geometry which I'd previously believed to be impossible in GTK. It's still not perfect, because GTK apparently provides no way for us to get hold of the X reparent event in order to support negative geometries in a manner which takes account of the WM borders; but for positive position it's at least an improvement on the previous version! [originally from svn r3078]
2003-04-08 13:49:12 +00:00
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(inst->window), "destroy",
G_CALLBACK(destroy), inst);
g_signal_connect(G_OBJECT(inst->window), "delete_event",
G_CALLBACK(delete_window), inst);
g_signal_connect(G_OBJECT(inst->window), "key_press_event",
G_CALLBACK(key_event), inst);
g_signal_connect(G_OBJECT(inst->window), "key_release_event",
G_CALLBACK(key_event), inst);
g_signal_connect(G_OBJECT(inst->window), "focus_in_event",
G_CALLBACK(focus_event), inst);
g_signal_connect(G_OBJECT(inst->window), "focus_out_event",
G_CALLBACK(focus_event), inst);
Stop using the GTK "configure-event" signal. I've been using that signal since the very first commit of this source file, as a combined way to be notified when the size of the drawing area changes (typically due to user window resizing actions) and also when the drawing area is first created and available to be drawn on. Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which the call to gtk_widget_show(inst->window) in new_session_window() has the side effect of delivering a spurious configure_event on the drawing area with size 1x46 pixels. This causes the terminal to resize itself to 1 column wide, and the mistake isn't rectified until a followup configure-event arrives after new_session_window returns to the GTK main loop. But that means terminal output can occur between those two configure events (the connection-sharing "Reusing a shared connection to host.name" is a good example), and when it does, it gets embarrassingly wrapped at one character per line down the left column. I briefly tried to bodge around this by trying to heuristically guess which configure events were real and which were spurious, but I have no faith in that strategy continuing to work. I think a better approach is to abandon configure-event completely, and move to a system in which the two purposes I was using it for are handled by two _different_ GTK signals, namely "size-allocate" (for knowing when we get resized) and "realize" (for knowing when the drawing area physically exists for us to start setting up Cairo or GDK machinery). The result seems to have fixed the silly one-column wrapping bug, and retained the ability to handle window resizes, on every GTK version I have conveniently available to test on, including GTK 3 both before and after these spurious configures started to happen.
2018-05-10 19:22:02 +00:00
g_signal_connect(G_OBJECT(inst->area), "realize",
G_CALLBACK(area_realised), inst);
g_signal_connect(G_OBJECT(inst->area), "size_allocate",
G_CALLBACK(area_size_allocate), inst);
Flip direction of window pos/size queries. Similarly to other recent changes, the frontend now proactively keeps Terminal up to date with the current position and size of the terminal window, so that escape-sequence queries can be answered immediately from the Terminal's own internal data structures without needing a call back to the frontend. Mostly this has let me remove explicit window-system API calls that retrieve the window position and size, in favour of having the front ends listen for WM_MOVE / WM_SIZE / ConfigureNotify events and track the position and size that way. One exception is that the window pixel size is still requested by Seat via a callback, to put in the wire-encoded termios settings. That won't be happening very much, so I'm leaving it this way round for the moment.
2021-02-07 19:59:21 +00:00
g_signal_connect(G_OBJECT(inst->window), "configure_event",
G_CALLBACK(window_configured), inst);
GTK 3: be aware of the window's scale factor. In GTK 3.10 and above, high-DPI support is arranged by each window having a property called a 'scale factor', which translates logical pixels as seen by most of the GTK API (widget and window sizes and positions, coordinates in the "draw" event, etc) into the physical pixels on the screen. This is handled more or less transparently, except that one side effect is that your Cairo-based drawing code had better be able to cope with that scaling without getting confused. PuTTY's isn't, because we do all our serious drawing on a separate Cairo surface we made ourselves, and then blit subrectangles of that to the window during updates. This has two bad consequences. Firstly, our surface has a size derived from what GTK told us the drawing area size is, i.e. corresponding to GTK's _logical_ pixels, so when the scale factor is (say) 2, our drawing takes place at half size and then gets scaled up by the final blit in the draw event, making it look blurry and unpleasant. Secondly, those final blits seem to end up offset by half a pixel, so that a second blit over the same subrectangle doesn't _quite_ completely wipe out the previously blitted data - so there's a ghostly rectangle left behind everywhere the cursor has been. It's not that GTK doesn't _let_ you find out the scale factor; it's just that it's in an out-of-the-way piece of API that you have to call specially. So now we do: our backing surface is now created at a pixel resolution matching the screen's real pixels, and we translate GTK's scale factor into an ordinary cairo_scale() before we commence drawing. So we still end up drawing the same text at the same size - and this strategy also means that non-text elements like cursor outlines and underlining will be scaled up with the screen DPI rather than stubbornly staying one physical pixel thick - but now it's nice and sharp at full screen resolution, and the subrectangle blits in the draw event are back to affecting the exact set of pixels we expect them to. One silly consequence is that, immediately after removing the last one, I've installed a handler for the GTK "configure-event" signal! That's because the GTK 3 docs claim that that's how you get notified that your scale factor has changed at run time (e.g. if you reconfigure the scale factor of a whole monitor in the GNOME settings dialog). Actually in practice I seem to find out via the "draw" event before "configure" bothers to tell me, but now I've got a usefully idempotent function for 'check whether the scale factor has changed and sort it out if so', I don't see any harm in calling it from anywhere it _might_ be useful.
2018-05-11 06:53:05 +00:00
#if GTK_CHECK_VERSION(3,10,0)
g_signal_connect(G_OBJECT(inst->area), "configure_event",
G_CALLBACK(area_configured), inst);
#endif
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#if GTK_CHECK_VERSION(3,0,0)
g_signal_connect(G_OBJECT(inst->area), "draw",
G_CALLBACK(draw_area), inst);
#else
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(inst->area), "expose_event",
G_CALLBACK(expose_area), inst);
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#endif
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(inst->area), "button_press_event",
G_CALLBACK(button_event), inst);
g_signal_connect(G_OBJECT(inst->area), "button_release_event",
G_CALLBACK(button_event), inst);
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(inst->area), "scroll_event",
G_CALLBACK(scroll_event), inst);
Manfred Schwarb points out that scroll wheel support stopped working 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]
2008-06-10 20:18:23 +00:00
#endif
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(inst->area), "motion_notify_event",
G_CALLBACK(motion_event), inst);
Support for dead keys and compose sequences on Unix, by instantiating 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]
2012-06-17 07:26:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
g_signal_connect(G_OBJECT(inst->imc), "commit",
G_CALLBACK(input_method_commit_event), inst);
#endif
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(inst->conf, CONF_scrollbar))
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(inst->sbar_adjust), "value_changed",
G_CALLBACK(scrollbar_moved), inst);
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
gtk_widget_add_events(GTK_WIDGET(inst->area),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GDK_KEY_PRESS_MASK | GDK_KEY_RELEASE_MASK |
GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK |
GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK
Make scroll events work again in GTK3. 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.
2015-09-25 13:09:57 +00:00
#if GTK_CHECK_VERSION(3,4,0)
| GDK_SMOOTH_SCROLL_MASK
#endif
);
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
set_window_icon(inst->window, main_icon, n_main_icon);
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
Window title configurability: -T to set it from the command line, support for the xterm escape sequences to set it, and support for the xterm escape sequence to query it. [originally from svn r2040]
2002-10-14 00:05:37 +00:00
gtk_widget_show(inst->window);
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
set_window_background(inst);
Fix the nasty flashing-light-grey-on-resize problem, after MCV helpfully alerted me to the existence of gdk_window_set_background(). [originally from svn r2129]
2002-10-25 11:58:59 +00:00
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
/*
* Set up the Ctrl+rightclick context menu.
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *menuitem;
char *s;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->menu = gtk_menu_new();
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
Fixes (mostly from Colin Watson, a couple redone by me) to make Unix PuTTY compile cleanly under gcc 4.6.0 without triggering any of its new warnings. [originally from svn r9169]
2011-05-07 10:57:19 +00:00
#define MKMENUITEM(title, func) do \
{ \
menuitem = gtk_menu_item_new_with_label(title); \
gtk_container_add(GTK_CONTAINER(inst->menu), menuitem); \
gtk_widget_show(menuitem); \
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(menuitem), "activate", \
G_CALLBACK(func), inst); \
Fixes (mostly from Colin Watson, a couple redone by me) to make Unix PuTTY compile cleanly under gcc 4.6.0 without triggering any of its new warnings. [originally from svn r9169]
2011-05-07 10:57:19 +00:00
} while (0)
#define MKSUBMENU(title) do \
{ \
menuitem = gtk_menu_item_new_with_label(title); \
gtk_container_add(GTK_CONTAINER(inst->menu), menuitem); \
gtk_widget_show(menuitem); \
} while (0)
#define MKSEP() do \
{ \
menuitem = gtk_menu_item_new(); \
gtk_container_add(GTK_CONTAINER(inst->menu), menuitem); \
gtk_widget_show(menuitem); \
} while (0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (new_session)
MKMENUITEM("New Session...", new_session_menuitem);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
MKMENUITEM("Restart Session", restart_session_menuitem);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inst->restartitem = menuitem;
gtk_widget_set_sensitive(inst->restartitem, false);
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 17:37:15 +00:00
MKMENUITEM("Duplicate Session", dup_session_menuitem);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (saved_sessions) {
inst->sessionsmenu = gtk_menu_new();
/* sessionsmenu will be updated when it's invoked */
/* XXX is this the right way to do dynamic menus in Gtk? */
MKMENUITEM("Saved Sessions", update_savedsess_menu);
gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuitem),
inst->sessionsmenu);
}
MKSEP();
Add a couple of ellipses in Unix context menu (like r759 on Windows). [originally from svn r8649] [r759 == 779069ccd3173cbeee604fd328aac750f5aef466]
2009-09-13 23:37:55 +00:00
MKMENUITEM("Change Settings...", change_settings_menuitem);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
MKSEP();
if (use_event_log)
MKMENUITEM("Event Log", event_log_menuitem);
MKSUBMENU("Special Commands");
inst->specialsmenu = gtk_menu_new();
gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuitem), inst->specialsmenu);
inst->specialsitem1 = menuitem;
MKSEP();
inst->specialsitem2 = menuitem;
gtk_widget_hide(inst->specialsitem1);
gtk_widget_hide(inst->specialsitem2);
MKMENUITEM("Clear Scrollback", clear_scrollback_menuitem);
MKMENUITEM("Reset Terminal", reset_terminal_menuitem);
MKSEP();
MKMENUITEM("Copy to " CLIPNAME_EXPLICIT_OBJECT,
Sort out clipboard-related menu items. The gtkapp.c menu now has a Copy as well as Paste option; those menu items, as well as the corresponding ones on the context menu and Copy All, now address sets of clipboards parametrised between OS X and ordinary GTK in unix.h. Also I've tweaked the wording of the context-menu items to not use the X-specific terminology "CLIPBOARD" on OS X.
2017-12-17 20:35:45 +00:00
copy_clipboard_menuitem);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
MKMENUITEM("Paste from " CLIPNAME_EXPLICIT_OBJECT,
Sort out clipboard-related menu items. The gtkapp.c menu now has a Copy as well as Paste option; those menu items, as well as the corresponding ones on the context menu and Copy All, now address sets of clipboards parametrised between OS X and ordinary GTK in unix.h. Also I've tweaked the wording of the context-menu items to not use the X-specific terminology "CLIPBOARD" on OS X.
2017-12-17 20:35:45 +00:00
paste_clipboard_menuitem);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
MKMENUITEM("Copy All", copy_all_menuitem);
MKSEP();
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
s = dupcat("About ", appname);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
MKMENUITEM(s, about_menuitem);
sfree(s);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
#undef MKMENUITEM
Fixes (mostly from Colin Watson, a couple redone by me) to make Unix PuTTY compile cleanly under gcc 4.6.0 without triggering any of its new warnings. [originally from svn r9169]
2011-05-07 10:57:19 +00:00
#undef MKSUBMENU
#undef MKSEP
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
inst->textcursor = make_mouse_ptr(inst, GDK_XTERM);
inst->rawcursor = make_mouse_ptr(inst, GDK_LEFT_PTR);
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
inst->waitcursor = make_mouse_ptr(inst, GDK_WATCH);
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
inst->blankcursor = make_mouse_ptr(inst, -1);
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 09:58:27 +00:00
inst->currcursor = inst->textcursor;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
show_mouseptr(inst, true);
A sensible minimum of do_text() and do_cursor() is now implemented. 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]
2002-10-10 10:40:30 +00:00
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
inst->eventlogstuff = eventlogstuff_new();
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
inst->term = term_init(inst->conf, &inst->ucsdata, &inst->termwin);
Support custom clipboard names under X. This required me to turn the drop-lists into combo boxes and add an extra string-typed Conf setting alongside each enumerated value.
2017-12-17 18:44:27 +00:00
setup_clipboards(inst, inst->term, inst->conf);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
inst->logctx = log_init(&inst->logpolicy, inst->conf);
Yet more global-removal. The static variables in logging.c are now 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]
2002-10-26 12:58:13 +00:00
term_provide_logctx(inst->term, inst->logctx);
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
Post-release destabilisation! Completely remove the struct type '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]
2011-07-14 18:52:21 +00:00
term_size(inst->term, inst->height, inst->width,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_get_int(inst->conf, CONF_savelines));
Various error-handling fixes, mostly in Unix PuTTY but one (failure to save a session) crosses over into the platform-independent side. [originally from svn r3041]
2003-04-01 18:10:25 +00:00
Remove TermWin's is_minimised method. Again, I've replaced it with a push-based notification going in the other direction, so that when the terminal output stream includes a query for 'is the window minimised?', the Terminal doesn't have to consult the TermWin, because it already knows the answer. The GTK API I'm using here (getting a GdkEventWindowState via GtkWidget's window-state-event) is not present in GTK 1. The API I was previously using (gdk_window_is_viewable) _is_, but it turns out that that API doesn't reliably give the right answer: it only checks visibility of GDK window ancestors, not X window ancestors. So in fact GTK 1 PuTTY/pterm was only ever _pretending_ to reliably support the 'am I minimised' terminal query. Now it won't pretend any more.
2021-02-07 19:59:20 +00:00
#if GTK_CHECK_VERSION(2,0,0)
/* Delay this signal connection until after inst->term exists */
g_signal_connect(G_OBJECT(inst->window), "window_state_event",
G_CALLBACK(window_state_event), inst);
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
inst->exited = false;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
GTK: handle synchronous connection-setup failures sensibly. This was one of a handful of remaining places in gtkwin.c where exit() is called incautiously. Of course, a failure to set up one SSH connection should only be fatal to that connection, not the whole process, so really we should be feeding into the connection_fatal system.
2017-11-27 19:32:39 +00:00
start_backend(inst);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
GTK: handle synchronous connection-setup failures sensibly. This was one of a handful of remaining places in gtkwin.c where exit() is called incautiously. Of course, a failure to set up one SSH connection should only be fatal to that connection, not the whole process, so really we should be feeding into the connection_fatal system.
2017-11-27 19:32:39 +00:00
if (inst->ldisc) /* early backend failure might make this NULL already */
ldisc_echoedit_update(inst->ldisc); /* cause ldisc to notice changes */
Begin destabilisation in the wake of 0.53! This checkin contains the 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]
2002-10-07 16:45:23 +00:00
}
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
Divide seat_set_trust_status into query and update. This complicates the API in one sense (more separate functions), but in another sense, simplifies it (each function does something simpler). When I start putting one Seat in front of another during SSH proxying, the latter will be more important - in particular, it means you can find out _whether_ a seat can support changing trust status without having to actually attempt a destructive modification.
2021-09-12 08:52:46 +00:00
static void gtk_seat_set_trust_status(Seat *seat, bool trusted)
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
{
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
term_set_trust_status(inst->term, trusted);
Divide seat_set_trust_status into query and update. This complicates the API in one sense (more separate functions), but in another sense, simplifies it (each function does something simpler). When I start putting one Seat in front of another during SSH proxying, the latter will be more important - in particular, it means you can find out _whether_ a seat can support changing trust status without having to actually attempt a destructive modification.
2021-09-12 08:52:46 +00:00
}
static bool gtk_seat_can_set_trust_status(Seat *seat)
{
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
return true;
}
Add a new seat method to return the cursor position. The motivation is for the SUPDUP protocol. The server may send a signal for the terminal to reset any input buffers. After this, the server will not know the state of the terminal, so it is required to send its cursor position back.
2019-04-04 19:17:24 +00:00
static bool gtk_seat_get_cursor_position(Seat *seat, int *x, int *y)
{
GtkFrontend *inst = container_of(seat, GtkFrontend, seat);
if (inst->term) {
term_get_cursor_position(inst->term, x, y);
return true;
}
return false;
}
Reference in New Issue Copy Permalink