github
/
putty
зеркало из https://github.com/github/putty.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
putty/unix/gtkwin.c

4653 строки
139 KiB
C
Исходник Обычный вид История

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 20:45:23 +04:00
/*
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 16:02:46 +03:00
* gtkwin.c: the main code that runs a PuTTY terminal emulator and
* 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 20:45:23 +04: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 18:21:12 +04: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 20:45:23 +04: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 14:40:30 +04: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 20:45:23 +04: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 18:21:12 +04: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 15:40:36 +03: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 22:09:42 +04: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 20:45:23 +04: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 16:40:05 +04: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 11:26:23 +04: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 16:40:05 +04: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 18:21:12 +04: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 20:45:23 +04: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 17:06:15 +03: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 16:14:05 +04: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 17:06:15 +03: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 20:45:23 +04: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 11:26:23 +04:00
#if GTK_CHECK_VERSION(2,0,0)
#include <gtk/gtkimmodule.h>
#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 22:09:42 +04:00
#define PUTTY_DO_GLOBALS /* actually _define_ globals */
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 15:20:34 +03: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-14 01:59:10 +04: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 22:09:42 +04: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 20:11:33 +04: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 17:53:43 +03:00
#include "gtkcompat.h"
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 14:40:23 +03:00
#include "gtkfont.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 17:44:24 +03: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 22:09:42 +04: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 15:05:51 +03:00
#ifndef NOT_X_WINDOWS
#include <gdk/gdkx.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>
#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 20:45:23 +04:00
#define CAT2(x,y) x ## y
#define CAT(x,y) CAT2(x,y)
#define ASSERT(x) enum {CAT(assertion_,__LINE__) = 1 / (x)}
r8854/5 broke compilation with Gtk 1.2. Grow a hack to cope. [originally from svn r8901] [r8854 == 14247162f7bd9969361cb8c6276c73dd18ea11ee] [r8855 == 7e16457d14ffae47303da8c48af98de68bb3a6ed]
2010-03-14 21:58:20 +03:00
#if GTK_CHECK_VERSION(2,0,0)
ASSERT(sizeof(long) <= sizeof(gsize));
#define LONG_TO_GPOINTER(l) GSIZE_TO_POINTER(l)
#define GPOINTER_TO_LONG(p) GPOINTER_TO_SIZE(p)
#else /* Gtk 1.2 */
ASSERT(sizeof(long) <= sizeof(gpointer));
#define LONG_TO_GPOINTER(l) ((gpointer)(long)(l))
#define GPOINTER_TO_LONG(p) ((long)(p))
#endif
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
/* Colours come in two flavours: configurable, and xterm-extended. */
#define NEXTCOLOURS 240 /* 216 colour-cube plus 24 shades of grey */
#define NALLCOLOURS (NCFGCOLOURS + NEXTCOLOURS)
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 14:40:30 +04:00
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 21:40:52 +04:00
GdkAtom compound_text_atom, utf8_string_atom;
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 21:37:15 +04:00
extern char **pty_argv; /* declared in pty.c */
extern int use_pty_argv;
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 16:20:21 +03:00
/*
* Timers are global across all sessions (even if we were handling
* multiple sessions, which we aren't), so the current timer ID is
* a global variable.
*/
static guint timer_id = 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 14:40:30 +04:00
struct gui_data {
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 04:05:37 +04:00
GtkWidget *window, *area, *sbar;
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04: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 17:04:18 +04:00
GtkWidget *menu, *specialsmenu, *specialsitem1, *specialsitem2,
*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 21:37:15 +04:00
GtkWidget *sessionsmenu;
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 11:02:31 +03:00
#ifndef NO_BACKING_PIXMAPS
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 14:40:30 +04: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 11:02:31 +03:00
#endif
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 11:26:23 +04: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 14:40:23 +03:00
unifont *fonts[4]; /* normal, bold, wide, widebold */
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 20:22:05 +03:00
#if GTK_CHECK_VERSION(2,0,0)
const char *geometry;
#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 17:49:12 +04:00
int xpos, ypos, gotpos, gravity;
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 20:22:05 +03:00
#endif
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 20:05:58 +03:00
GdkCursor *rawcursor, *textcursor, *blankcursor, *waitcursor, *currcursor;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
GdkColor cols[NALLCOLOURS];
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 16:22:14 +03: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 14:40:30 +04: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 16:22:14 +03: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 15:24:25 +04:00
wchar_t *pastein_data;
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 19:17:56 +03:00
int direct_to_font;
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 15:24:25 +04:00
int pastein_data_len;
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 23:57:17 +04:00
char *pasteout_data, *pasteout_data_ctext, *pasteout_data_utf8;
int pasteout_data_len, pasteout_data_ctext_len, pasteout_data_utf8_len;
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 18:42:56 +04:00
int font_width, font_height;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
int width, height;
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 16:44:01 +04:00
int ignore_sbar;
Don't cause the mouse pointer to reappear just because it's changed shape. [originally from svn r2053]
2002-10-15 03:39:07 +04:00
int mouseptr_visible;
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 20:05:58 +03:00
int busy_status;
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 20:06:08 +04:00
guint toplevel_callback_idle_id;
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
int idle_fn_scheduled, quit_fn_scheduled;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04: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 20:34:45 +03: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 22:52:21 +04: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 21:30:14 +03:00
int master_fd, master_func_id;
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 14:16:19 +04:00
void *ldisc;
Port forwarding module now passes backend handles around properly. As a result I've now been able to turn the global variables `back' and `backhandle' into module-level statics in the individual front ends. Now _that's_ progress! [originally from svn r2142]
2002-10-26 14:33:59 +04:00
Backend *back;
void *backhandle;
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 15:08:59 +04:00
Terminal *term;
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 16:58:13 +04:00
void *logctx;
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 21:30:14 +03:00
int 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 21:28:23 +03: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 22:52:21 +04:00
Conf *conf;
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 22:46:45 +04:00
void *eventlogstuff;
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 21:37:15 +04:00
char *progname, **gtkargvstart;
int ngtkargs;
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 22:03:06 +04:00
guint32 input_event_time; /* Timestamp of the most recent input event. */
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 13:07:27 +03:00
int reconfiguring;
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 22:52:21 +04: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 19:09:22 +04: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 22:52:21 +04: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 23:05:56 +03: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 21:00:25 +03:00
int meta_mod_mask;
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 16:58:13 +04: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 22:52:21 +04:00
static void cache_conf_values(struct gui_data *inst)
{
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 19:09:22 +04: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 22:52:21 +04: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 21:00:25 +03:00
#ifdef OSX_META_KEY_CONFIG
inst->meta_mod_mask = 0;
if (conf_get_int(inst->conf, CONF_osx_option_meta))
inst->meta_mod_mask |= GDK_MOD1_MASK;
if (conf_get_int(inst->conf, CONF_osx_command_meta))
inst->meta_mod_mask |= GDK_MOD2_MASK;
#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 22:52:21 +04: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 16:58:13 +04:00
struct draw_ctx {
struct gui_data *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 23:05:56 +03:00
unifont_drawctx uctx;
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 14:40:30 +04:00
};
static int send_raw_mouse;
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 13:15:42 +03:00
static const char *app_name = "pterm";
First attempt at a Unix port of Plink. Seems to basically work; doesn't yet use the SSH agent, no way to specify arbitrary config options, no manpage yet, couple of other fiddly things need doing, but it makes SSH connections and doesn't fall over horribly so I say it's a good start. Now to run it under valgrind... [originally from svn r2165]
2002-10-31 22:49:52 +03: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 17:04:18 +04:00
static void start_backend(struct gui_data *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 20:06:22 +04:00
static void exit_callback(void *vinst);
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 17:04:18 +04:00
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 21:43:45 +03:00
char *x_get_default(const char *key)
First attempt at a Unix port of Plink. Seems to basically work; doesn't yet use the SSH agent, no way to specify arbitrary config options, no manpage yet, couple of other fiddly things need doing, but it makes SSH connections and doesn't fall over horribly so I say it's a good start. Now to run it under valgrind... [originally from svn r2165]
2002-10-31 22:49:52 +03: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 18:35:19 +03:00
#ifndef NOT_X_WINDOWS
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
return XGetDefault(GDK_DISPLAY_XDISPLAY(gdk_display_get_default()),
app_name, key);
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 18:35:19 +03:00
#else
return NULL;
#endif
First attempt at a Unix port of Plink. Seems to basically work; doesn't yet use the SSH agent, no way to specify arbitrary config options, no manpage yet, couple of other fiddly things need doing, but it makes SSH connections and doesn't fall over horribly so I say it's a good start. Now to run it under valgrind... [originally from svn r2165]
2002-10-31 22:49:52 +03: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 13:15:42 +03:00
void connection_fatal(void *frontend, const char *p, ...)
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 22:10:25 +04:00
{
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 22:36:27 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:10:25 +04:00
va_list ap;
char *msg;
va_start(ap, p);
msg = dupvprintf(p, ap);
va_end(ap);
fatal_message_box(inst->window, msg);
sfree(msg);
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 20:06:22 +04:00
queue_toplevel_callback(exit_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 22:10:25 +04:00
}
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 21:06:29 +03: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 21:38:59 +04: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 21:06:29 +03:00
{
if (!strcmp(name, "Font"))
Don't use "server:fixed" as the default font without X. If we're not supporting server-side fonts, it's utterly silly to set one as the default! Instead, we use Pango's guarantee that some reasonably sensible monospaced font will be made available under the name "Monospace", and use that at a reasonable default size of 12pt.
2015-08-31 15:24:09 +03: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 15:54:40 +03:00
else
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 21:38:59 +04:00
return fontspec_new("");
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 15:54:40 +03: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 15:01:57 +04: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 15:54:40 +03:00
{
if (!strcmp(name, "LogFileName"))
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 15:01:57 +04: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 15:54:40 +03:00
else
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 15:01:57 +04: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 15:54:40 +03: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 18:29:02 +04:00
if (!strcmp(name, "SerialLine"))
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 21:06:29 +03:00
return NULL;
}
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 21:43:45 +03: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 21:06:29 +03:00
{
if (!strcmp(name, "CloseOnExit"))
And another bit missing from the settings changes: pterm's platform default for CloseOnExit was encoded wrongly. Hopefully this should be everything now; I'm really starting to get sick of picking up the pieces after my two checkins yesterday. Perhaps I should have waited until I had a brain before doing them in the first place. [originally from svn r2746]
2003-01-28 15:06:37 +03:00
return 2; /* maps to FORCE_ON after painful rearrangement :-( */
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 17:55:47 +04:00
if (!strcmp(name, "WinNameAlways"))
return 0; /* X natively supports icon titles, so use 'em by default */
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 21:06:29 +03:00
return def;
}
Remove outdated comment. [originally from svn r8628]
2009-08-22 03:25:48 +04:00
/* Dummy routine, only required in plink. */
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 19:12:47 +03:00
void frontend_echoedit_update(void *frontend, int echo, int edit)
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 22:09:42 +04:00
{
}
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 17:57:08 +04:00
char *get_ttymode(void *frontend, const char *mode)
{
struct gui_data *inst = (struct gui_data *)frontend;
return term_get_ttymode(inst->term, mode);
}
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 22:36:27 +04:00
int from_backend(void *frontend, int is_stderr, const char *data, int len)
{
struct gui_data *inst = (struct gui_data *)frontend;
return term_data(inst->term, is_stderr, data, len);
}
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 23:24:09 +03:00
int from_backend_untrusted(void *frontend, const char *data, int len)
{
struct gui_data *inst = (struct gui_data *)frontend;
return term_data_untrusted(inst->term, data, len);
}
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 15:44:03 +04:00
int from_backend_eof(void *frontend)
{
return TRUE; /* do respond to incoming EOF with outgoing */
}
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 13:15:42 +03:00
int get_userpass_input(prompts_t *p, const unsigned char *in, int inlen)
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 23:24:09 +03:00
{
struct gui_data *inst = (struct gui_data *)p->frontend;
int ret;
ret = cmdline_get_passwd_input(p, in, inlen);
if (ret == -1)
ret = term_get_userpass_input(inst->term, p, in, inlen);
return ret;
}
Colin's const-fixing Patch Of Death. Seems to build fine on Windows as well as Unix, so it can go in. [originally from svn r3162]
2003-05-04 18:18:18 +04:00
void logevent(void *frontend, 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 22:09:42 +04:00
{
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 22:36:27 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:46:45 +04:00
log_eventlog(inst->logctx, string);
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 22:09:42 +04: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 16:58:13 +04:00
int font_dimension(void *frontend, int which)/* 0 for width, 1 for height */
Don't forget to initialise the pixel size parameters of the window as passed to the pty... [originally from svn r2064]
2002-10-15 19:16:21 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
Don't forget to initialise the pixel size parameters of the window as passed to the pty... [originally from svn r2064]
2002-10-15 19:16:21 +04:00
if (which)
return inst->font_height;
else
return inst->font_width;
}
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 22:09:42 +04:00
/*
* Translate a raw mouse button designation (LEFT, MIDDLE, RIGHT)
* into a cooked one (SELECT, EXTEND, PASTE).
*
* 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 19:23:48 +03: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 22:09:42 +04: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 16:58:13 +04:00
/* struct gui_data *inst = (struct gui_data *)frontend; */
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 22:09:42 +04:00
if (button == MBT_LEFT)
return MBT_SELECT;
if (button == MBT_MIDDLE)
return MBT_PASTE;
if (button == MBT_RIGHT)
return MBT_EXTEND;
return 0; /* shouldn't happen */
}
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 15:21:07 +04:00
/*
* Return the top-level GtkWindow associated with a particular
* front end instance.
*/
void *get_window(void *frontend)
{
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 22:36:27 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 15:21:07 +04:00
return 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 22:09:42 +04:00
/*
* Minimise or restore the window in response to a server-side
* request.
*/
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 16:58:13 +04:00
void set_iconic(void *frontend, int iconic)
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 22:09:42 +04: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 18:31:06 +04:00
/*
* GTK 1.2 doesn't know how to do this.
*/
#if GTK_CHECK_VERSION(2,0,0)
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 18:31:06 +04:00
if (iconic)
gtk_window_iconify(GTK_WINDOW(inst->window));
else
gtk_window_deiconify(GTK_WINDOW(inst->window));
#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 22:09:42 +04:00
}
/*
* Move the window in response to a server-side request.
*/
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 16:58:13 +04:00
void move_window(void *frontend, 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 18:31:06 +04: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_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 17:53:43 +03: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 18:31:06 +04: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 22:09:42 +04:00
}
/*
* Move the window to the top or bottom of the z-order in response
* to a server-side request.
*/
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 16:58:13 +04:00
void set_zorder(void *frontend, int 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 18:31:06 +04:00
if (top)
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03: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 18:31:06 +04:00
else
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03: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 22:09:42 +04:00
}
/*
* Refresh the window in response to a server-side request.
*/
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 16:58:13 +04:00
void refresh_window(void *frontend)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 15:08:59 +04: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 22:09:42 +04:00
}
/*
* Maximise or restore the window in response to a server-side
* request.
*/
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 16:58:13 +04:00
void set_zoomed(void *frontend, int zoomed)
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 22:09:42 +04: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 18:31:06 +04:00
/*
* GTK 1.2 doesn't know how to do this.
*/
#if GTK_CHECK_VERSION(2,0,0)
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:33:29 +03:00
if (zoomed)
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 18:31:06 +04:00
gtk_window_maximize(GTK_WINDOW(inst->window));
else
gtk_window_unmaximize(GTK_WINDOW(inst->window));
#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 22:09:42 +04:00
}
/*
* Report whether the window is iconic, for terminal reports.
*/
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 16:58:13 +04:00
int is_iconic(void *frontend)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
return !gdk_window_is_viewable(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 22:09:42 +04:00
}
/*
* Report the window's position, for terminal reports.
*/
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 16:58:13 +04:00
void get_window_pos(void *frontend, 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 18:31:06 +04: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_position(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 17:53:43 +03:00
gdk_window_get_position(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 18:31:06 +04: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 22:09:42 +04:00
}
/*
* Report the window's pixel size, for terminal reports.
*/
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 16:58:13 +04:00
void get_window_pixels(void *frontend, 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 18:31:06 +04: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), 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 17:53:43 +03:00
gdk_window_get_size(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 18:31:06 +04: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 22:09:42 +04:00
}
/*
* Return the window or icon title.
*/
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 16:58:13 +04:00
char *get_window_title(void *frontend, int icon)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
Stupid braino in get_window_title (thanks Colin): window and icon titles were being reported the wrong way round. Should fix half of Debian bug #191751. [originally from svn r3173]
2003-05-10 13:05:41 +04:00
return icon ? inst->icontitle : inst->wintitle;
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 22:09:42 +04: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 20:45:23 +04:00
gint delete_window(GtkWidget *widget, GdkEvent *event, gpointer data)
{
Implement Warn On Close. [originally from svn r3099]
2003-04-11 22:15:47 +04:00
struct gui_data *inst = (struct gui_data *)data;
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 22:52:21 +04:00
if (!inst->exited && conf_get_int(inst->conf, CONF_warn_on_close)) {
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 22:36:27 +04:00
if (!reallyclose(inst))
Implement Warn On Close. [originally from svn r3099]
2003-04-11 22:15:47 +04: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 20:45:23 +04:00
return FALSE;
}
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 20:05:58 +03:00
static void update_mouseptr(struct gui_data *inst)
{
switch (inst->busy_status) {
case BUSY_NOT:
if (!inst->mouseptr_visible) {
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
inst->blankcursor);
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 20:05:58 +03:00
} else if (send_raw_mouse) {
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
inst->rawcursor);
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 20:05:58 +03:00
} else {
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
inst->textcursor);
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 20:05:58 +03:00
}
break;
case BUSY_WAITING: /* XXX can we do better? */
case BUSY_CPU:
/* We always display these cursors. */
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gdk_window_set_cursor(gtk_widget_get_window(inst->area),
inst->waitcursor);
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 20:05:58 +03:00
break;
default:
assert(0);
}
}
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 16:58:13 +04:00
static void show_mouseptr(struct gui_data *inst, int show)
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 13:58:27 +04: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 22:52:21 +04:00
if (!conf_get_int(inst->conf, CONF_hide_mouseptr))
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 13:58:27 +04:00
show = 1;
Don't cause the mouse pointer to reappear just because it's changed shape. [originally from svn r2053]
2002-10-15 03:39:07 +04: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 20:05:58 +03: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 13:58:27 +04: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 23:05:56 +03:00
static void draw_backing_rect(struct gui_data *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 22:14:14 +04: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 20:45:23 +04:00
gint configure_area(GtkWidget *widget, GdkEventConfigure *event, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 16:44:01 +04:00
int w, h, need_size = 0;
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 20:45:23 +04: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 15:03:44 +04:00
/*
* See if the terminal size has changed, in which case we must
* let the terminal know.
*/
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 22:52:21 +04:00
w = (event->width - 2*inst->window_border) / inst->font_width;
h = (event->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 22:00:50 +04:00
if (w != inst->width || h != inst->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 22:52:21 +04: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);
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 16:44:01 +04:00
need_size = 1;
}
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 15:03:44 +04: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 11:02:31 +03:00
#ifndef NO_BACKING_PIXMAPS
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 15:03:44 +04:00
if (inst->pixmap) {
gdk_pixmap_unref(inst->pixmap);
inst->pixmap = NULL;
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04: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 20:45:23 +04:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
inst->pixmap = gdk_pixmap_new(gtk_widget_get_window(widget),
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 22:52:21 +04:00
(w * inst->font_width + 2*inst->window_border),
(h * inst->font_height + 2*inst->window_border), -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 11:02:31 +03: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 15:03:44 +04:00
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 22:14:14 +04: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 15:03:44 +04:00
if (need_size && inst->term) {
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 22:52:21 +04:00
term_size(inst->term, h, w, conf_get_int(inst->conf, CONF_savelines));
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 16:44:01 +04: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 15:03:44 +04:00
if (inst->term)
term_invalidate(inst->term);
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 11:26:23 +04:00
#if GTK_CHECK_VERSION(2,0,0)
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gtk_im_context_set_client_window(inst->imc, gtk_widget_get_window(widget));
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 11:26:23 +04: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 20:45:23 +04: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 16:34:19 +03:00
#ifdef DRAW_TEXT_CAIRO
static void cairo_setup_dctx(struct draw_ctx *dctx)
{
cairo_get_matrix(dctx->uctx.u.cairo.cr,
&dctx->uctx.u.cairo.origmatrix);
cairo_set_line_width(dctx->uctx.u.cairo.cr, 1.0);
cairo_set_line_cap(dctx->uctx.u.cairo.cr, CAIRO_LINE_CAP_SQUARE);
cairo_set_line_join(dctx->uctx.u.cairo.cr, CAIRO_LINE_JOIN_MITER);
/* 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 */
cairo_set_antialias(dctx->uctx.u.cairo.cr, CAIRO_ANTIALIAS_NONE);
}
#endif
#if GTK_CHECK_VERSION(3,0,0)
static gint draw_area(GtkWidget *widget, cairo_t *cr, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
if (inst->term) {
struct draw_ctx adctx, *dctx = &adctx;
GdkRectangle dirtyrect;
dctx->inst = inst;
dctx->uctx.type = DRAWTYPE_CAIRO;
dctx->uctx.u.cairo.widget = widget;
dctx->uctx.u.cairo.cr = cr;
cairo_setup_dctx(dctx);
gdk_cairo_get_clip_rectangle(cr, &dirtyrect);
/*
* As in window.c, we clear the 'immediately' flag in the
* term_paint() call if the terminal has an update pending, in
* case we're constrained within this event to only draw on
* the exposed rectangle of the window. (Because if the whole
* of a character cell needs a redraw due to a terminal
* contents change, the last thing we want is to give it a
* _partial_ redraw here due to system-imposed clipping, and
* then have the next main terminal update believe it's been
* redrawn in full.)
*
* I don't actually know if GTK draw events will constrain us
* in this way, but it's best to be careful...
*/
term_paint(inst->term, dctx,
(dirtyrect.x - inst->window_border) / inst->font_width,
(dirtyrect.y - inst->window_border) / inst->font_height,
(dirtyrect.x + dirtyrect.width -
inst->window_border) / inst->font_width,
(dirtyrect.y + dirtyrect.height -
inst->window_border) / inst->font_height,
!inst->term->window_update_pending);
}
return TRUE;
}
#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 20:45:23 +04:00
gint expose_area(GtkWidget *widget, GdkEventExpose *event, gpointer data)
{
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)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 20:45:23 +04: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 11:02:31 +03: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 20:45:23 +04: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 22:09:42 +04:00
* Pass the exposed rectangle to terminal.c, which will call us
* back to do the actual painting.
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 20:45:23 +04:00
*/
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
if (inst->pixmap) {
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gdk_draw_pixmap(gtk_widget_get_window(widget),
(gtk_widget_get_style(widget)->fg_gc
[gtk_widget_get_state(widget)]),
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
inst->pixmap,
event->area.x, event->area.y,
event->area.x, event->area.y,
event->area.width, event->area.height);
}
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 11:02:31 +03:00
#else
if (inst->term) {
Context ctx = get_ctx(inst);
term_paint(inst->term, ctx,
(event->area.x - inst->window_border) / inst->font_width,
(event->area.y - inst->window_border) / inst->font_height,
(event->area.x + event->area.width -
inst->window_border) / inst->font_width,
(event->area.y + event->area.height -
inst->window_border) / inst->font_height,
!inst->term->window_update_pending);
free_ctx(ctx);
}
#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 22:09:42 +04: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 20:45:23 +04: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 16:34:19 +03: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 20:45:23 +04:00
#define KEY_PRESSED(k) \
(inst->keystate[(k) / 32] & (1 << ((k) % 32)))
gint key_event(GtkWidget *widget, GdkEventKey *event, gpointer data)
{
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)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 19:52:42 +03: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 15:10:48 +04:00
wchar_t ucsoutput[2];
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 19:52:42 +03:00
int ucsval, start, end, special, output_charset, use_ucsoutput;
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-06 03:45:20 +04:00
int nethack_mode, app_keypad_mode;
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 20:45:23 +04: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 22:03:06 +04: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 21:18:24 +04:00
/* By default, nothing is generated. */
end = start = 0;
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 15:10:48 +04: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 19:52:42 +03:00
output_charset = CS_ISO8859_1;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04: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 20:35:17 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
/*
* Condition this mess in if you want to debug keyboard events as
* they come in to this function (e.g. because some particular
* port of GDK is producing an unexpected arrangement of
* modifiers).
*/
#define TRY(val, prefix, string) \
if ((val) == prefix ## string) printf("%s", #string); else
#define GIVE_UP(val) \
printf("%d", (int)(val))
#define TRY_MASK(val, prefix, string, suffix) \
if ((val) & prefix ## string ## suffix) { \
(val) &= ~ prefix ## string ## suffix; \
printf("%s", #string); \
if (val) printf("|"); \
}
#define GIVE_UP_MASK(val) \
do \
{ \
if ((val)) printf("%d", (int)(val)); \
} while (0)
printf("key_event: type=");
TRY(event->type, GDK_KEY_, PRESS)
TRY(event->type, GDK_KEY_, RELEASE)
GIVE_UP(event->type);
printf(" keyval=");
TRY(event->keyval, GDK_KEY_, Alt_L)
TRY(event->keyval, GDK_KEY_, Alt_R)
TRY(event->keyval, GDK_KEY_, BackSpace)
TRY(event->keyval, GDK_KEY_, Begin)
TRY(event->keyval, GDK_KEY_, Break)
TRY(event->keyval, GDK_KEY_, Delete)
TRY(event->keyval, GDK_KEY_, Down)
TRY(event->keyval, GDK_KEY_, End)
TRY(event->keyval, GDK_KEY_, Escape)
TRY(event->keyval, GDK_KEY_, F10)
TRY(event->keyval, GDK_KEY_, F11)
TRY(event->keyval, GDK_KEY_, F12)
TRY(event->keyval, GDK_KEY_, F13)
TRY(event->keyval, GDK_KEY_, F14)
TRY(event->keyval, GDK_KEY_, F15)
TRY(event->keyval, GDK_KEY_, F16)
TRY(event->keyval, GDK_KEY_, F17)
TRY(event->keyval, GDK_KEY_, F18)
TRY(event->keyval, GDK_KEY_, F19)
TRY(event->keyval, GDK_KEY_, F1)
TRY(event->keyval, GDK_KEY_, F20)
TRY(event->keyval, GDK_KEY_, F2)
TRY(event->keyval, GDK_KEY_, F3)
TRY(event->keyval, GDK_KEY_, F4)
TRY(event->keyval, GDK_KEY_, F5)
TRY(event->keyval, GDK_KEY_, F6)
TRY(event->keyval, GDK_KEY_, F7)
TRY(event->keyval, GDK_KEY_, F8)
TRY(event->keyval, GDK_KEY_, F9)
TRY(event->keyval, GDK_KEY_, Home)
TRY(event->keyval, GDK_KEY_, Insert)
TRY(event->keyval, GDK_KEY_, ISO_Left_Tab)
TRY(event->keyval, GDK_KEY_, KP_0)
TRY(event->keyval, GDK_KEY_, KP_1)
TRY(event->keyval, GDK_KEY_, KP_2)
TRY(event->keyval, GDK_KEY_, KP_3)
TRY(event->keyval, GDK_KEY_, KP_4)
TRY(event->keyval, GDK_KEY_, KP_5)
TRY(event->keyval, GDK_KEY_, KP_6)
TRY(event->keyval, GDK_KEY_, KP_7)
TRY(event->keyval, GDK_KEY_, KP_8)
TRY(event->keyval, GDK_KEY_, KP_9)
TRY(event->keyval, GDK_KEY_, KP_Add)
TRY(event->keyval, GDK_KEY_, KP_Begin)
TRY(event->keyval, GDK_KEY_, KP_Decimal)
TRY(event->keyval, GDK_KEY_, KP_Delete)
TRY(event->keyval, GDK_KEY_, KP_Divide)
TRY(event->keyval, GDK_KEY_, KP_Down)
TRY(event->keyval, GDK_KEY_, KP_End)
TRY(event->keyval, GDK_KEY_, KP_Enter)
TRY(event->keyval, GDK_KEY_, KP_Home)
TRY(event->keyval, GDK_KEY_, KP_Insert)
TRY(event->keyval, GDK_KEY_, KP_Left)
TRY(event->keyval, GDK_KEY_, KP_Multiply)
TRY(event->keyval, GDK_KEY_, KP_Page_Down)
TRY(event->keyval, GDK_KEY_, KP_Page_Up)
TRY(event->keyval, GDK_KEY_, KP_Right)
TRY(event->keyval, GDK_KEY_, KP_Subtract)
TRY(event->keyval, GDK_KEY_, KP_Up)
TRY(event->keyval, GDK_KEY_, Left)
TRY(event->keyval, GDK_KEY_, Meta_L)
TRY(event->keyval, GDK_KEY_, Meta_R)
TRY(event->keyval, GDK_KEY_, Num_Lock)
TRY(event->keyval, GDK_KEY_, Page_Down)
TRY(event->keyval, GDK_KEY_, Page_Up)
TRY(event->keyval, GDK_KEY_, Return)
TRY(event->keyval, GDK_KEY_, Right)
TRY(event->keyval, GDK_KEY_, Tab)
TRY(event->keyval, GDK_KEY_, Up)
TRY(event->keyval, GDK_KEY_, Shift_L)
TRY(event->keyval, GDK_KEY_, Shift_R)
TRY(event->keyval, GDK_KEY_, Control_L)
TRY(event->keyval, GDK_KEY_, Control_R)
TRY(event->keyval, GDK_KEY_, Caps_Lock)
TRY(event->keyval, GDK_KEY_, Shift_Lock)
TRY(event->keyval, GDK_KEY_, Super_L)
TRY(event->keyval, GDK_KEY_, Super_R)
TRY(event->keyval, GDK_KEY_, Hyper_L)
TRY(event->keyval, GDK_KEY_, Hyper_R)
GIVE_UP(event->keyval);
printf(" state=");
{
int val = event->state;
TRY_MASK(val, GDK_, SHIFT, _MASK)
TRY_MASK(val, GDK_, LOCK, _MASK)
TRY_MASK(val, GDK_, CONTROL, _MASK)
TRY_MASK(val, GDK_, MOD1, _MASK)
TRY_MASK(val, GDK_, MOD2, _MASK)
TRY_MASK(val, GDK_, MOD3, _MASK)
TRY_MASK(val, GDK_, MOD4, _MASK)
TRY_MASK(val, GDK_, MOD5, _MASK)
TRY_MASK(val, GDK_, SUPER, _MASK)
TRY_MASK(val, GDK_, HYPER, _MASK)
TRY_MASK(val, GDK_, META, _MASK)
GIVE_UP_MASK(val);
}
printf(" hardware_keycode=%d is_modifier=%s\n",
(int)event->hardware_keycode, event->is_modifier ? "TRUE" : "FALSE");
#endif /* KEY_EVENT_DIAGNOSTICS */
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
/*
* If Alt is being released after typing an Alt+numberpad
* sequence, we should generate the code that was typed.
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 20:34:45 +03: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 21:18:24 +04: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 11:26:23 +04: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 18:23:54 +03: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 11:26:23 +04:00
inst->alt_keycode >= 0 && inst->alt_digits > 1) {
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
#ifdef KEY_DEBUGGING
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 11:26:23 +04:00
printf("Alt key up, keycode = %d\n", inst->alt_keycode);
#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)
if (gtk_im_context_filter_keypress(inst->imc, event))
return TRUE;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04: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 22:09:42 +04:00
if (event->type == GDK_KEY_PRESS) {
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 16:14:05 +04:00
#ifdef KEY_DEBUGGING
{
int i;
printf("keypress: keyval = %04x, state = %08x; string =",
event->keyval, event->state);
for (i = 0; event->string[i]; i++)
printf(" %02x", (unsigned char) event->string[i]);
printf("\n");
}
#endif
/*
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
* NYI: Compose key (!!! requires Unicode faff before even trying)
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 16:14:05 +04:00
*/
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04: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).
*/
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 18:23:54 +03: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 ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04: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 20:34:45 +03:00
inst->alt_digits = 0;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
goto done; /* this generates nothing else */
}
/*
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 21:00:25 +03:00
* If we're seeing a numberpad key press with Meta down,
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
* consider adding it to alt_keycode if that's sensible.
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 21:00:25 +03:00
* Anything _else_ with Meta down cancels any possibility
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
* of an ALT keycode: we set alt_keycode to -2.
*/
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 21:00:25 +03:00
if ((event->state & inst->meta_mod_mask) && inst->alt_keycode != -2) {
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
int digit = -1;
switch (event->keyval) {
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 18:23:54 +03:00
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;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
}
if (digit < 0)
inst->alt_keycode = -2; /* it's invalid */
else {
#ifdef KEY_DEBUGGING
printf("Adding digit %d to keycode %d", digit,
inst->alt_keycode);
#endif
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 20:34:45 +03:00
inst->alt_digits++;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
#ifdef KEY_DEBUGGING
printf(" gives new code %d\n", inst->alt_keycode);
#endif
/* Having used this digit, we now do nothing more with it. */
goto done;
}
}
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
/*
* Shift-PgUp and Shift-PgDn don't even generate keystrokes
* at all.
*/
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_Page_Up &&
(event->state & GDK_SHIFT_MASK)) {
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 22:52:21 +04:00
term_scroll(inst->term, 0, -inst->height/2);
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
return TRUE;
}
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_Page_Up &&
(event->state & GDK_CONTROL_MASK)) {
Ctrl-PgUp and Ctrl-PgDn now scroll by one line on Unix and Windows [originally from svn r2582]
2003-01-14 14:24:26 +03:00
term_scroll(inst->term, 0, -1);
return TRUE;
}
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_Page_Down &&
(event->state & GDK_SHIFT_MASK)) {
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 22:52:21 +04:00
term_scroll(inst->term, 0, +inst->height/2);
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
return TRUE;
}
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_Page_Down &&
(event->state & GDK_CONTROL_MASK)) {
Ctrl-PgUp and Ctrl-PgDn now scroll by one line on Unix and Windows [originally from svn r2582]
2003-01-14 14:24:26 +03: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 13:54:36 +04:00
Shift-Ins pastes. [originally from svn r2034]
2002-10-13 15:27:39 +04:00
/*
* Neither does Shift-Ins.
*/
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_Insert &&
(event->state & GDK_SHIFT_MASK)) {
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 16:58:13 +04:00
request_paste(inst);
Shift-Ins pastes. [originally from svn r2034]
2002-10-13 15:27:39 +04: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 13:27:56 +04:00
special = FALSE;
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 15:10:48 +04:00
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 13:27:56 +04:00
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-06 03:45:20 +04:00
nethack_mode = conf_get_int(inst->conf, CONF_nethack_keypad);
app_keypad_mode = (inst->term->app_keypad_keys &&
!conf_get_int(inst->conf, CONF_no_applic_k));
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 16:14:05 +04: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 19:52:42 +03:00
#if !GTK_CHECK_VERSION(2,0,0)
/*
* 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;
strncpy(output+1, event->string, lenof(output)-1);
#else
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-06 03:45:20 +04: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.
*/
if (app_keypad_mode &&
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 18:23:54 +03:00
(event->keyval == GDK_KEY_Num_Lock ||
event->keyval == GDK_KEY_KP_Divide ||
event->keyval == GDK_KEY_KP_Multiply ||
event->keyval == GDK_KEY_KP_Subtract ||
event->keyval == GDK_KEY_KP_Add ||
event->keyval == GDK_KEY_KP_Enter ||
event->keyval == GDK_KEY_KP_0 ||
event->keyval == GDK_KEY_KP_Insert ||
event->keyval == GDK_KEY_KP_1 ||
event->keyval == GDK_KEY_KP_End ||
event->keyval == GDK_KEY_KP_2 ||
event->keyval == GDK_KEY_KP_Down ||
event->keyval == GDK_KEY_KP_3 ||
event->keyval == GDK_KEY_KP_Page_Down ||
event->keyval == GDK_KEY_KP_4 ||
event->keyval == GDK_KEY_KP_Left ||
event->keyval == GDK_KEY_KP_5 ||
event->keyval == GDK_KEY_KP_Begin ||
event->keyval == GDK_KEY_KP_6 ||
event->keyval == GDK_KEY_KP_Right ||
event->keyval == GDK_KEY_KP_7 ||
event->keyval == GDK_KEY_KP_Home ||
event->keyval == GDK_KEY_KP_8 ||
event->keyval == GDK_KEY_KP_Up ||
event->keyval == GDK_KEY_KP_9 ||
event->keyval == GDK_KEY_KP_Page_Up ||
event->keyval == GDK_KEY_KP_Decimal ||
event->keyval == GDK_KEY_KP_Delete)) {
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-06 03:45:20 +04:00
/* app keypad; do nothing */
} else if (nethack_mode &&
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 18:23:54 +03:00
(event->keyval == GDK_KEY_KP_1 ||
event->keyval == GDK_KEY_KP_End ||
event->keyval == GDK_KEY_KP_2 ||
event->keyval == GDK_KEY_KP_Down ||
event->keyval == GDK_KEY_KP_3 ||
event->keyval == GDK_KEY_KP_Page_Down ||
event->keyval == GDK_KEY_KP_4 ||
event->keyval == GDK_KEY_KP_Left ||
event->keyval == GDK_KEY_KP_5 ||
event->keyval == GDK_KEY_KP_Begin ||
event->keyval == GDK_KEY_KP_6 ||
event->keyval == GDK_KEY_KP_Right ||
event->keyval == GDK_KEY_KP_7 ||
event->keyval == GDK_KEY_KP_Home ||
event->keyval == GDK_KEY_KP_8 ||
event->keyval == GDK_KEY_KP_Up ||
event->keyval == GDK_KEY_KP_9 ||
event->keyval == GDK_KEY_KP_Page_Up)) {
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-06 03:45:20 +04:00
/* nethack mode; do nothing */
} else {
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 21:10:29 +03: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).
*/
} else
#endif
if (gtk_im_context_filter_keypress(inst->imc, event))
return 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-06 03:45:20 +04: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 11:26:23 +04:00
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 19:52:42 +03: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;
{
Add some missing consts in character set handling. [originally from svn r9291]
2011-09-16 23:18:52 +04:00
wchar_t widedata[32];
const wchar_t *wp;
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 19:52:42 +03:00
int wlen;
int ulen;
wlen = mb_to_wc(DEFAULT_CODEPAGE, 0,
event->string, strlen(event->string),
widedata, lenof(widedata)-1);
wp = widedata;
ulen = charset_from_unicode(&wp, &wlen, output+1, lenof(output)-2,
CS_UTF8, NULL, NULL, 0);
output[1+ulen] = '\0';
}
#endif
if (!output[1] &&
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 15:10:48 +04:00
(ucsval = keysym_to_unicode(event->keyval)) >= 0) {
ucsoutput[0] = '\033';
ucsoutput[1] = ucsval;
use_ucsoutput = TRUE;
end = 2;
} else {
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 19:52:42 +03:00
output[lenof(output)-1] = '\0';
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 15:10:48 +04:00
end = strlen(output);
}
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 21:00:25 +03:00
if (event->state & inst->meta_mod_mask) {
Oops - that fix wasn't _quite_ right, since it killed all non-function keys completely :-/ [originally from svn r2096]
2002-10-17 20:58:24 +04:00
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 21:10:29 +03: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;
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)) {
ucsoutput[0] = '\033';
ucsoutput[1] = gdk_keyval_to_unicode(new_keyval);
use_ucsoutput = TRUE;
end = 2;
}
}
#endif
Oops - that fix wasn't _quite_ right, since it killed all non-function keys completely :-/ [originally from svn r2096]
2002-10-17 20:58:24 +04: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 16:14:05 +04:00
/* Control-` is the same as Control-\ (unless gtk has a better idea) */
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 19:52:42 +03:00
if (!output[1] && event->keyval == '`' &&
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 16:14:05 +04:00
(event->state & GDK_CONTROL_MASK)) {
output[1] = '\x1C';
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
end = 2;
}
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 15:00:42 +03: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) {
if (output[1] >= '3' && output[1] <= '7') {
/* ^3,...,^7 map to 0x1B,...,0x1F */
output[1] += '\x1B' - '3';
} else if (output[1] == '2') {
/* ^2 is ^@, i.e. \0 */
output[1] = '\0';
} else if (output[1] == '8') {
/* ^8 is DEL */
output[1] = '\x7F';
} else if (output[1] == '/') {
/* ^/ is the same as ^_ */
output[1] = '\x1F';
} else if (output[1] >= 0x40 && output[1] < 0x7F) {
/* Everything anywhere near the alphabetics just gets
* masked. */
output[1] &= 0x1F;
}
/* Anything else, e.g. '0', is unchanged. */
}
Ctrl-Break now sends a Break signal (previously it was equivalent to Ctrl-C). [originally from svn r7295] [this svn revision also touched putty-wishlist]
2007-02-18 17:02:39 +03:00
/* Control-Break sends a Break special to the backend */
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_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 16:14:05 +04:00
(event->state & GDK_CONTROL_MASK)) {
Ctrl-Break now sends a Break signal (previously it was equivalent to Ctrl-C). [originally from svn r7295] [this svn revision also touched putty-wishlist]
2007-02-18 17:02:39 +03:00
if (inst->back)
inst->back->special(inst->backhandle, TS_BRK);
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 13:27:56 +04:00
}
/* We handle Return ourselves, because it needs to be flagged as
* special to ldisc. */
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_Return) {
Implement the ldisc `special' mechanism in Unix, without which local line editing didn't work at all. [originally from svn r3107]
2003-04-12 13:27:56 +04:00
output[1] = '\015';
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 15:10:48 +04:00
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 13:27:56 +04:00
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 16:14:05 +04:00
}
/* Control-2, Control-Space and Control-@ are NUL */
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 19:52:42 +03:00
if (!output[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 16:14:05 +04:00
(event->keyval == ' ' || event->keyval == '2' ||
event->keyval == '@') &&
(event->state & (GDK_SHIFT_MASK |
GDK_CONTROL_MASK)) == GDK_CONTROL_MASK) {
output[1] = '\0';
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
end = 2;
}
/* Control-Shift-Space is 160 (ISO8859 nonbreaking space) */
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 19:52:42 +03:00
if (!output[1] && event->keyval == ' ' &&
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 16:14:05 +04:00
(event->state & (GDK_SHIFT_MASK | GDK_CONTROL_MASK)) ==
(GDK_SHIFT_MASK | GDK_CONTROL_MASK)) {
output[1] = '\240';
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 19:52:42 +03:00
output_charset = CS_ISO8859_1;
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
end = 2;
}
/* We don't let GTK tell us what Backspace is! We know better. */
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_BackSpace &&
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 16:14:05 +04:00
!(event->state & GDK_SHIFT_MASK)) {
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 22:52:21 +04:00
output[1] = conf_get_int(inst->conf, CONF_bksp_is_delete) ?
'\x7F' : '\x08';
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
end = 2;
Implement the ldisc `special' mechanism in Unix, without which local line editing didn't work at all. [originally from svn r3107]
2003-04-12 13:27:56 +04:00
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 16:14:05 +04:00
}
Bug `shift-backspace': whichever of ^H and ^? is configured for Backspace, Shift-Backspace should do the _other_ one. Thanks to Justin Bradford. [originally from svn r2079]
2002-10-16 13:40:36 +04:00
/* For Shift Backspace, do opposite of what is configured. */
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_BackSpace &&
Bug `shift-backspace': whichever of ^H and ^? is configured for Backspace, Shift-Backspace should do the _other_ one. Thanks to Justin Bradford. [originally from svn r2079]
2002-10-16 13:40:36 +04:00
(event->state & GDK_SHIFT_MASK)) {
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 22:52:21 +04:00
output[1] = conf_get_int(inst->conf, CONF_bksp_is_delete) ?
'\x08' : '\x7F';
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 15:10:48 +04:00
use_ucsoutput = FALSE;
Bug `shift-backspace': whichever of ^H and ^? is configured for Backspace, Shift-Backspace should do the _other_ one. Thanks to Justin Bradford. [originally from svn r2079]
2002-10-16 13:40:36 +04:00
end = 2;
Implement the ldisc `special' mechanism in Unix, without which local line editing didn't work at all. [originally from svn r3107]
2003-04-12 13:27:56 +04:00
special = TRUE;
Bug `shift-backspace': whichever of ^H and ^? is configured for Backspace, Shift-Backspace should do the _other_ one. Thanks to Justin Bradford. [originally from svn r2079]
2002-10-16 13:40:36 +04: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 16:14:05 +04:00
/* Shift-Tab is ESC [ Z */
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_ISO_Left_Tab ||
(event->keyval == GDK_KEY_Tab &&
(event->state & GDK_SHIFT_MASK))) {
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 16:14:05 +04:00
end = 1 + sprintf(output+1, "\033[Z");
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
}
Under OS X Leopard, we seem not to consistently get the Tab key translated for us. Be prepared to do it manually as a fallback. [originally from svn r7913]
2008-03-09 18:32:20 +03:00
/* 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. */
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 18:23:54 +03:00
if (event->keyval == GDK_KEY_Tab && end <= 1) {
Under OS X Leopard, we seem not to consistently get the Tab key translated for us. Be prepared to do it manually as a fallback. [originally from svn r7913]
2008-03-09 18:32:20 +03: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 16:14:05 +04:00
Support NetHack keypad mode. :-) [originally from svn r2046]
2002-10-14 14:06:07 +04:00
/*
* NetHack keypad mode.
*/
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-06 03:45:20 +04:00
if (nethack_mode) {
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 13:15:42 +03:00
const char *keys = NULL;
Support NetHack keypad mode. :-) [originally from svn r2046]
2002-10-14 14:06:07 +04:00
switch (event->keyval) {
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 18:23:54 +03:00
case GDK_KEY_KP_1: case GDK_KEY_KP_End:
keys = "bB\002"; break;
case GDK_KEY_KP_2: case GDK_KEY_KP_Down:
keys = "jJ\012"; break;
case GDK_KEY_KP_3: case GDK_KEY_KP_Page_Down:
keys = "nN\016"; break;
case GDK_KEY_KP_4: case GDK_KEY_KP_Left:
keys = "hH\010"; break;
case GDK_KEY_KP_5: case GDK_KEY_KP_Begin:
keys = "..."; break;
case GDK_KEY_KP_6: case GDK_KEY_KP_Right:
keys = "lL\014"; break;
case GDK_KEY_KP_7: case GDK_KEY_KP_Home:
keys = "yY\031"; break;
case GDK_KEY_KP_8: case GDK_KEY_KP_Up:
keys = "kK\013"; break;
case GDK_KEY_KP_9: case GDK_KEY_KP_Page_Up:
keys = "uU\025"; break;
Support NetHack keypad mode. :-) [originally from svn r2046]
2002-10-14 14:06:07 +04:00
}
if (keys) {
end = 2;
David Damerell tells me I should be using Ctrl-hjklyubn rather than Shift-hjklyubn for batch movement in NetHack, because they have subtly different behaviour within the game and the Ctrl-moves are more useful. Unfortunately, PuTTY's NetHack keypad mode doesn't support Ctrl-moves. Therefore, it does now :-) [originally from svn r6593]
2006-03-08 21:10:12 +03:00
if (event->state & GDK_CONTROL_MASK)
output[1] = keys[2];
else if (event->state & GDK_SHIFT_MASK)
Support NetHack keypad mode. :-) [originally from svn r2046]
2002-10-14 14:06:07 +04:00
output[1] = keys[1];
else
output[1] = keys[0];
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 15:10:48 +04:00
use_ucsoutput = FALSE;
Support NetHack keypad mode. :-) [originally from svn r2046]
2002-10-14 14:06:07 +04:00
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 16:14:05 +04:00
/*
* Application keypad mode.
*/
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-06 03:45:20 +04:00
if (app_keypad_mode) {
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 16:14:05 +04:00
int xkey = 0;
switch (event->keyval) {
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 18:23:54 +03:00
case GDK_KEY_Num_Lock: xkey = 'P'; break;
case GDK_KEY_KP_Divide: xkey = 'Q'; break;
case GDK_KEY_KP_Multiply: xkey = 'R'; break;
case GDK_KEY_KP_Subtract: xkey = 'S'; 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 16:14:05 +04:00
/*
* Keypad + is tricky. It covers a space that would
* be taken up on the VT100 by _two_ keys; so we
* let Shift select between the two. Worse still,
* in xterm function key mode we change which two...
*/
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 18:23:54 +03:00
case GDK_KEY_KP_Add:
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 22:52:21 +04:00
if (conf_get_int(inst->conf, CONF_funky_type) == FUNKY_XTERM) {
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 16:14:05 +04:00
if (event->state & GDK_SHIFT_MASK)
xkey = 'l';
else
xkey = 'k';
} else if (event->state & GDK_SHIFT_MASK)
xkey = 'm';
else
xkey = 'l';
break;
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 18:23:54 +03:00
case GDK_KEY_KP_Enter: xkey = 'M'; break;
case GDK_KEY_KP_0: case GDK_KEY_KP_Insert: xkey = 'p'; break;
case GDK_KEY_KP_1: case GDK_KEY_KP_End: xkey = 'q'; break;
case GDK_KEY_KP_2: case GDK_KEY_KP_Down: xkey = 'r'; break;
case GDK_KEY_KP_3: case GDK_KEY_KP_Page_Down: xkey = 's'; break;
case GDK_KEY_KP_4: case GDK_KEY_KP_Left: xkey = 't'; break;
case GDK_KEY_KP_5: case GDK_KEY_KP_Begin: xkey = 'u'; break;
case GDK_KEY_KP_6: case GDK_KEY_KP_Right: xkey = 'v'; break;
case GDK_KEY_KP_7: case GDK_KEY_KP_Home: xkey = 'w'; break;
case GDK_KEY_KP_8: case GDK_KEY_KP_Up: xkey = 'x'; break;
case GDK_KEY_KP_9: case GDK_KEY_KP_Page_Up: xkey = 'y'; break;
case GDK_KEY_KP_Decimal: case GDK_KEY_KP_Delete:
xkey = 'n'; 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 16:14:05 +04:00
}
if (xkey) {
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 15:08:59 +04:00
if (inst->term->vt52_mode) {
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 16:14:05 +04:00
if (xkey >= 'P' && xkey <= 'S')
end = 1 + sprintf(output+1, "\033%c", xkey);
else
end = 1 + sprintf(output+1, "\033?%c", xkey);
} else
end = 1 + sprintf(output+1, "\033O%c", xkey);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
}
/*
* Next, all the keys that do tilde codes. (ESC '[' nn '~',
* for integer decimal nn.)
*
* We also deal with the weird ones here. Linux VCs replace F1
* to F5 by ESC [ [ A to ESC [ [ E. rxvt doesn't do _that_, but
* does replace Home and End (1~ and 4~) by ESC [ H and ESC O w
* respectively.
*/
{
int code = 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 22:52:21 +04:00
int funky_type = conf_get_int(inst->conf, CONF_funky_type);
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 16:14:05 +04:00
switch (event->keyval) {
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 18:23:54 +03:00
case GDK_KEY_F1:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 23 : 11);
break;
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 18:23:54 +03:00
case GDK_KEY_F2:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 24 : 12);
break;
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 18:23:54 +03:00
case GDK_KEY_F3:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 25 : 13);
break;
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 18:23:54 +03:00
case GDK_KEY_F4:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 26 : 14);
break;
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 18:23:54 +03:00
case GDK_KEY_F5:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 28 : 15);
break;
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 18:23:54 +03:00
case GDK_KEY_F6:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 29 : 17);
break;
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 18:23:54 +03:00
case GDK_KEY_F7:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 31 : 18);
break;
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 18:23:54 +03:00
case GDK_KEY_F8:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 32 : 19);
break;
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 18:23:54 +03:00
case GDK_KEY_F9:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 33 : 20);
break;
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 18:23:54 +03:00
case GDK_KEY_F10:
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 16:14:05 +04:00
code = (event->state & GDK_SHIFT_MASK ? 34 : 21);
break;
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 18:23:54 +03:00
case GDK_KEY_F11:
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 16:14:05 +04:00
code = 23;
break;
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 18:23:54 +03:00
case GDK_KEY_F12:
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 16:14:05 +04:00
code = 24;
break;
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 18:23:54 +03:00
case GDK_KEY_F13:
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 16:14:05 +04:00
code = 25;
break;
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 18:23:54 +03:00
case GDK_KEY_F14:
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 16:14:05 +04:00
code = 26;
break;
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 18:23:54 +03:00
case GDK_KEY_F15:
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 16:14:05 +04:00
code = 28;
break;
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 18:23:54 +03:00
case GDK_KEY_F16:
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 16:14:05 +04:00
code = 29;
break;
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 18:23:54 +03:00
case GDK_KEY_F17:
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 16:14:05 +04:00
code = 31;
break;
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 18:23:54 +03:00
case GDK_KEY_F18:
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 16:14:05 +04:00
code = 32;
break;
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 18:23:54 +03:00
case GDK_KEY_F19:
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 16:14:05 +04:00
code = 33;
break;
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 18:23:54 +03:00
case GDK_KEY_F20:
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 16:14:05 +04:00
code = 34;
break;
}
if (!(event->state & GDK_CONTROL_MASK)) switch (event->keyval) {
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 18:23:54 +03:00
case GDK_KEY_Home: case GDK_KEY_KP_Home:
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 16:14:05 +04:00
code = 1;
break;
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 18:23:54 +03:00
case GDK_KEY_Insert: case GDK_KEY_KP_Insert:
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 16:14:05 +04:00
code = 2;
break;
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 18:23:54 +03:00
case GDK_KEY_Delete: case GDK_KEY_KP_Delete:
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 16:14:05 +04:00
code = 3;
break;
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 18:23:54 +03:00
case GDK_KEY_End: case GDK_KEY_KP_End:
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 16:14:05 +04:00
code = 4;
break;
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 18:23:54 +03:00
case GDK_KEY_Page_Up: case GDK_KEY_KP_Page_Up:
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 16:14:05 +04:00
code = 5;
break;
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 18:23:54 +03:00
case GDK_KEY_Page_Down: case GDK_KEY_KP_Page_Down:
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 16:14:05 +04:00
code = 6;
break;
}
/* Reorder edit keys to physical order */
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 22:52:21 +04:00
if (funky_type == FUNKY_VT400 && code <= 6)
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 16:14:05 +04:00
code = "\0\2\1\4\5\3\6"[code];
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 15:08:59 +04:00
if (inst->term->vt52_mode && code > 0 && code <= 6) {
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 16:14:05 +04:00
end = 1 + sprintf(output+1, "\x1B%c", " HLMEIG"[code]);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
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 22:52:21 +04:00
if (funky_type == FUNKY_SCO && /* SCO function keys */
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 16:14:05 +04:00
code >= 11 && code <= 34) {
char codes[] = "MNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@[\\]^_`{";
int index = 0;
switch (event->keyval) {
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 18:23:54 +03:00
case GDK_KEY_F1: index = 0; break;
case GDK_KEY_F2: index = 1; break;
case GDK_KEY_F3: index = 2; break;
case GDK_KEY_F4: index = 3; break;
case GDK_KEY_F5: index = 4; break;
case GDK_KEY_F6: index = 5; break;
case GDK_KEY_F7: index = 6; break;
case GDK_KEY_F8: index = 7; break;
case GDK_KEY_F9: index = 8; break;
case GDK_KEY_F10: index = 9; break;
case GDK_KEY_F11: index = 10; break;
case GDK_KEY_F12: index = 11; 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 16:14:05 +04:00
}
if (event->state & GDK_SHIFT_MASK) index += 12;
if (event->state & GDK_CONTROL_MASK) index += 24;
end = 1 + sprintf(output+1, "\x1B[%c", codes[index]);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
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 22:52:21 +04:00
if (funky_type == FUNKY_SCO && /* SCO small keypad */
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 16:14:05 +04:00
code >= 1 && code <= 6) {
char codes[] = "HL.FIG";
if (code == 3) {
output[1] = '\x7F';
end = 2;
} else {
end = 1 + sprintf(output+1, "\x1B[%c", codes[code-1]);
}
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
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 22:52:21 +04:00
if ((inst->term->vt52_mode || funky_type == FUNKY_VT100P) &&
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 20:11:33 +04:00
code >= 11 && code <= 24) {
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 16:14:05 +04:00
int offt = 0;
if (code > 15)
offt++;
if (code > 21)
offt++;
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 15:08:59 +04:00
if (inst->term->vt52_mode)
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 16:14:05 +04:00
end = 1 + sprintf(output+1,
"\x1B%c", code + 'P' - 11 - offt);
else
end = 1 + sprintf(output+1,
"\x1BO%c", code + 'P' - 11 - offt);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
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 22:52:21 +04:00
if (funky_type == FUNKY_LINUX && code >= 11 && code <= 15) {
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 16:14:05 +04:00
end = 1 + sprintf(output+1, "\x1B[[%c", code + 'A' - 11);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
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 22:52:21 +04:00
if (funky_type == FUNKY_XTERM && code >= 11 && code <= 14) {
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 15:08:59 +04:00
if (inst->term->vt52_mode)
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 16:14:05 +04:00
end = 1 + sprintf(output+1, "\x1B%c", code + 'P' - 11);
else
end = 1 + sprintf(output+1, "\x1BO%c", code + 'P' - 11);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
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 22:52:21 +04:00
if ((code == 1 || code == 4) &&
conf_get_int(inst->conf, CONF_rxvt_homeend)) {
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 16:14:05 +04:00
end = 1 + sprintf(output+1, code == 1 ? "\x1B[H" : "\x1BOw");
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
if (code) {
end = 1 + sprintf(output+1, "\x1B[%d~", code);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
}
/*
* Cursor keys. (This includes the numberpad cursor keys,
* if we haven't already done them due to app keypad mode.)
*
* Here we also process un-numlocked un-appkeypadded KP5,
* which sends ESC [ G.
*/
{
int xkey = 0;
switch (event->keyval) {
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 18:23:54 +03:00
case GDK_KEY_Up: case GDK_KEY_KP_Up: xkey = 'A'; break;
case GDK_KEY_Down: case GDK_KEY_KP_Down: xkey = 'B'; break;
case GDK_KEY_Right: case GDK_KEY_KP_Right: xkey = 'C'; break;
case GDK_KEY_Left: case GDK_KEY_KP_Left: xkey = 'D'; break;
case GDK_KEY_Begin: case GDK_KEY_KP_Begin: xkey = 'G'; 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 16:14:05 +04:00
}
if (xkey) {
Centralise generation of the control sequences for arrow keys into a function in terminal.c, and replace the cloned-and-hacked handling code in all our front ends with calls to that. This was intended for code cleanliness, but a side effect is to make the GTK arrow-key handling support disabling of application cursor key mode in the Features panel. Previously that checkbox was accidentally ignored, and nobody seems to have noticed before! [originally from svn r8896]
2010-03-06 18:50:26 +03:00
end = 1 + format_arrow_key(output+1, inst->term, xkey,
event->state & GDK_CONTROL_MASK);
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 15:10:48 +04:00
use_ucsoutput = FALSE;
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 16:14:05 +04:00
goto done;
}
}
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
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 16:14:05 +04:00
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04: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 16:14:05 +04:00
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
if (end-start > 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 16:14:05 +04:00
#ifdef KEY_DEBUGGING
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
int i;
printf("generating sequence:");
for (i = start; i < end; i++)
printf(" %02x", (unsigned char) output[i]);
printf("\n");
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 16:14:05 +04:00
#endif
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
Implement the ldisc `special' mechanism in Unix, without which local line editing didn't work at all. [originally from svn r3107]
2003-04-12 13:27:56 +04:00
if (special) {
/*
* For special control characters, the character set
* should never matter.
*/
output[end] = '\0'; /* NUL-terminate */
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 17:04:18 +04:00
if (inst->ldisc)
ldisc_send(inst->ldisc, output+start, -2, 1);
Implement the ldisc `special' mechanism in Unix, without which local line editing didn't work at all. [originally from svn r3107]
2003-04-12 13:27:56 +04:00
} else if (!inst->direct_to_font) {
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 15:10:48 +04:00
if (!use_ucsoutput) {
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 17:04:18 +04:00
if (inst->ldisc)
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 19:52:42 +03:00
lpage_send(inst->ldisc, output_charset, output+start,
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 17:04:18 +04:00
end-start, 1);
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 15:10:48 +04:00
} else {
/*
* We generated our own Unicode key data from the
* keysym, so use that instead.
*/
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 17:04:18 +04:00
if (inst->ldisc)
luni_send(inst->ldisc, ucsoutput+start, end-start, 1);
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 15:10:48 +04: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-02 01:25:25 +03:00
} else {
/*
* In direct-to-font mode, we just send the string
* exactly as we received it.
*/
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 17:04:18 +04:00
if (inst->ldisc)
ldisc_send(inst->ldisc, output+start, end-start, 1);
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-02 01:25:25 +03: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 15:20:34 +03: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 16:58:13 +04:00
show_mouseptr(inst, 0);
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 15:08:59 +04:00
term_seen_key_event(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 22:09:42 +04: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 20:45:23 +04: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 11:26:23 +04:00
#if GTK_CHECK_VERSION(2,0,0)
void input_method_commit_event(GtkIMContext *imc, gchar *str, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
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 21:24:20 +04:00
if (inst->ldisc)
lpage_send(inst->ldisc, CS_UTF8, str, strlen(str), 1);
Add the missing code to treat data coming from the input method as keypresses for purposes of hiding the mouse pointer and resetting the scrollback. [originally from svn r9568]
2012-06-18 22:10:59 +04:00
show_mouseptr(inst, 0);
term_seen_key_event(inst->term);
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 11:26:23 +04:00
}
#endif
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-11 00:18:23 +04:00
gboolean button_internal(struct gui_data *inst, guint32 timestamp,
GdkEventType type, guint ebutton, guint state,
gdouble ex, gdouble ey)
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 15:24:25 +04: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 20:40:46 +04:00
int shift, ctrl, alt, x, y, button, act, 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 15:24:25 +04: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 22:03:06 +04:00
/* Remember the timestamp. */
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-11 00:18:23 +04:00
inst->input_event_time = timestamp;
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 22:03:06 +04: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 16:58:13 +04:00
show_mouseptr(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 13:58:27 +04: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-11 00:18:23 +04:00
shift = state & GDK_SHIFT_MASK;
ctrl = 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 21:00:25 +03:00
alt = 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 20:05:00 +04: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 20:40:46 +04:00
raw_mouse_mode =
send_raw_mouse && !(shift && conf_get_int(inst->conf,
CONF_mouse_override));
if (!raw_mouse_mode) {
if (ebutton == 4 && type == GDK_BUTTON_PRESS) {
term_scroll(inst->term, 0, -5);
return TRUE;
}
if (ebutton == 5 && type == GDK_BUTTON_PRESS) {
term_scroll(inst->term, 0, +5);
return TRUE;
}
}
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-11 00:18:23 +04:00
if (ebutton == 3 && ctrl) {
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 20:05:00 +04:00
gtk_menu_popup(GTK_MENU(inst->menu), NULL, NULL, NULL, NULL,
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-11 00:18:23 +04:00
ebutton, timestamp);
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 20:05:00 +04:00
return TRUE;
}
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-11 00:18:23 +04:00
if (ebutton == 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 15:24:25 +04:00
button = MBT_LEFT;
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-11 00:18:23 +04:00
else if (ebutton == 2)
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 15:24:25 +04:00
button = MBT_MIDDLE;
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-11 00:18:23 +04:00
else if (ebutton == 3)
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 15:24:25 +04:00
button = MBT_RIGHT;
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 20:40:46 +04:00
else if (ebutton == 4)
button = MBT_WHEEL_UP;
else if (ebutton == 5)
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 15:24:25 +04:00
else
return FALSE; /* don't even know what button! */
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-11 00:18:23 +04:00
switch (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 15:24:25 +04: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;
default: return FALSE; /* don't know this event type */
}
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 20:40:46 +04:00
if (raw_mouse_mode && act != MA_CLICK && act != MA_RELEASE)
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 15:24:25 +04:00
return TRUE; /* we ignore these in raw mouse mode */
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 22:52:21 +04:00
x = (ex - inst->window_border) / inst->font_width;
y = (ey - 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 15:24:25 +04: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 19:16:45 +03:00
term_mouse(inst->term, button, translate_button(button), act,
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 15:24:25 +04:00
return TRUE;
}
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-11 00:18:23 +04:00
gboolean button_event(GtkWidget *widget, GdkEventButton *event, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
return button_internal(inst, event->time, event->type, event->button,
event->state, event->x, event->y);
}
#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)
{
struct gui_data *inst = (struct gui_data *)data;
guint button;
if (event->direction == GDK_SCROLL_UP)
button = 4;
else if (event->direction == GDK_SCROLL_DOWN)
button = 5;
else
return FALSE;
return button_internal(inst, event->time, GDK_BUTTON_PRESS,
button, event->state, event->x, event->y);
}
#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 15:24:25 +04:00
gint motion_event(GtkWidget *widget, GdkEventMotion *event, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
int shift, ctrl, alt, x, y, button;
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 22:03:06 +04:00
/* Remember the timestamp. */
inst->input_event_time = event->time;
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 16:58:13 +04:00
show_mouseptr(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 13:58:27 +04: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 15:24:25 +04: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 21:00:25 +03: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 15:24:25 +04:00
if (event->state & GDK_BUTTON1_MASK)
button = MBT_LEFT;
else if (event->state & GDK_BUTTON2_MASK)
button = MBT_MIDDLE;
else if (event->state & GDK_BUTTON3_MASK)
button = MBT_RIGHT;
else
return FALSE; /* don't even know what button! */
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 22:52:21 +04: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 15:24:25 +04: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 19:16:45 +03:00
term_mouse(inst->term, button, translate_button(button), MA_DRAG,
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 15:24:25 +04:00
return TRUE;
}
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 14:16:19 +04:00
void frontend_keypress(void *handle)
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 18:21:12 +04:00
{
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 14:16:19 +04:00
struct gui_data *inst = (struct gui_data *)handle;
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 18:21:12 +04:00
/*
* If our child process has exited but not closed, terminate on
* any keypress.
*/
if (inst->exited)
Add some missing calls to cleanup_exit. [originally from svn r9936]
2013-07-19 21:44:47 +04:00
cleanup_exit(0);
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 18:21:12 +04:00
}
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 20:06:22 +04:00
static void exit_callback(void *vinst)
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 20:45:23 +04:00
{
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 20:06:22 +04:00
struct gui_data *inst = (struct gui_data *)vinst;
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 22:52:21 +04: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 13:18:34 +04: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 22:10:25 +04:00
if (!inst->exited &&
(exitcode = inst->back->exitcode(inst->backhandle)) >= 0) {
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 21:30:14 +03:00
inst->exited = TRUE;
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 22:52:21 +04: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))
Make sure we do notify_remote_exit(ssh->frontend) _before_ connection_fatal(), since the latter is entitled to destroy the backend so `ssh' may no longer be valid once it returns. For the Unix port, switch exit(0) to gtk_main_quit() in notify_remote_exit(), so that we don't exit before the subsequent connection_fatal()! [originally from svn r5445]
2005-03-05 20:56:28 +03:00
gtk_main_quit(); /* just go */
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 17:04:18 +04:00
if (inst->ldisc) {
ldisc_free(inst->ldisc);
inst->ldisc = NULL;
}
Remove another pointless null check, this time of inst->back in the function which has just dereferenced it to get the exit code. [originally from svn r9907]
2013-07-11 21:24:14 +04:00
inst->back->free(inst->backhandle);
inst->backhandle = NULL;
inst->back = NULL;
term_provide_resize_fn(inst->term, NULL, NULL);
update_specials_menu(inst);
In Unix PuTTY, grey out "Restart Session" when it doesn't apply (as the Windows version does), rather than hiding it completely. [originally from svn r8650]
2009-09-14 03:41:55 +04:00
gtk_widget_set_sensitive(inst->restartitem, TRUE);
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 13:18:34 +04: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 21:36:27 +03:00
}
GTK 3 prep: write a replacement for gtk_quit_add(). GTK 2 has deprecated it and provided no replacement; a bug tracker entry I found on the subject suggested that it was functionality that didn't really belong in GTK, and glib ought to provide a replacement instead, which would be a perfectly fine thing to suggest if they had waited for glib to get round to doing so *before* throwing out a function people were actually using. Sigh. Anyway, it turns out that subsidiary invocations of gtk_main() don't happen inside GTK as far as I can see, so all I need to do is to make sure my own invocations of gtk_main() are followed by a cleanup function which runs any quit functions that I've registered. That was the last deprecated GTK function, so we now build cleanly with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that has migrating to Cairo drawing as a prerequisite.)
2015-08-09 13:33:43 +03:00
/*
* Replacement code for the gtk_quit_add() function, which GTK2 - in
* their unbounded wisdom - deprecated without providing any usable
* replacement, and which we were using to ensure that our idle
* function for toplevel callbacks was only run from the outermost
* gtk_main().
*
* We maintain a global variable with a list of 'struct gui_data'
* instances on which we should call inst_post_main() when a
* subsidiary gtk_main() terminates; then we must make sure that all
* our subsidiary calls to gtk_main() are followed by a call to
* post_main().
*
* This is kind of overkill in the sense that at the time of writing
* we don't actually ever run more than one 'struct gui_data' instance
* in the same process, but we're _so nearly_ prepared to do that that
* I want to remain futureproof against the possibility of doing so in
* future.
*/
struct post_main_context {
struct post_main_context *next;
struct gui_data *inst;
};
struct post_main_context *post_main_list_head = NULL;
static void request_post_main(struct gui_data *inst)
{
struct post_main_context *node = snew(struct post_main_context);
node->next = post_main_list_head;
node->inst = inst;
post_main_list_head = node;
}
static void inst_post_main(struct gui_data *inst);
void post_main(void)
{
while (post_main_list_head) {
struct post_main_context *node = post_main_list_head;
post_main_list_head = node->next;
inst_post_main(node->inst);
sfree(node);
}
}
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 21:36:27 +03:00
void notify_remote_exit(void *frontend)
{
struct gui_data *inst = (struct gui_data *)frontend;
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 20:06:22 +04: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 16:20:21 +03: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 20:45:23 +04:00
Don't run toplevel callbacks in modal dialogs. Because some of them can call gtk_main_quit(), which completely confuses the dialog box system. [originally from svn r10029]
2013-08-18 14:56:20 +04:00
static void notify_toplevel_callback(void *frontend);
GTK 3 prep: write a replacement for gtk_quit_add(). GTK 2 has deprecated it and provided no replacement; a bug tracker entry I found on the subject suggested that it was functionality that didn't really belong in GTK, and glib ought to provide a replacement instead, which would be a perfectly fine thing to suggest if they had waited for glib to get round to doing so *before* throwing out a function people were actually using. Sigh. Anyway, it turns out that subsidiary invocations of gtk_main() don't happen inside GTK as far as I can see, so all I need to do is to make sure my own invocations of gtk_main() are followed by a cleanup function which runs any quit functions that I've registered. That was the last deprecated GTK function, so we now build cleanly with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that has migrating to Cairo drawing as a prerequisite.)
2015-08-09 13:33:43 +03:00
static void inst_post_main(struct gui_data *inst)
Don't run toplevel callbacks in modal dialogs. Because some of them can call gtk_main_quit(), which completely confuses the dialog box system. [originally from svn r10029]
2013-08-18 14:56:20 +04:00
{
GTK 3 prep: write a replacement for gtk_quit_add(). GTK 2 has deprecated it and provided no replacement; a bug tracker entry I found on the subject suggested that it was functionality that didn't really belong in GTK, and glib ought to provide a replacement instead, which would be a perfectly fine thing to suggest if they had waited for glib to get round to doing so *before* throwing out a function people were actually using. Sigh. Anyway, it turns out that subsidiary invocations of gtk_main() don't happen inside GTK as far as I can see, so all I need to do is to make sure my own invocations of gtk_main() are followed by a cleanup function which runs any quit functions that I've registered. That was the last deprecated GTK function, so we now build cleanly with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that has migrating to Cairo drawing as a prerequisite.)
2015-08-09 13:33:43 +03:00
if (gtk_main_level() == 1) {
notify_toplevel_callback(inst);
inst->quit_fn_scheduled = FALSE;
} else {
/* Apparently we're _still_ more than one level deep in
* gtk_main() instances, so we'll need another callback for
* when we get out of the next one. */
request_post_main(inst);
}
Don't run toplevel callbacks in modal dialogs. Because some of them can call gtk_main_quit(), which completely confuses the dialog box system. [originally from svn r10029]
2013-08-18 14:56:20 +04:00
}
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 20:06:08 +04:00
static gint idle_toplevel_callback_func(gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
Don't run toplevel callbacks in modal dialogs. Because some of them can call gtk_main_quit(), which completely confuses the dialog box system. [originally from svn r10029]
2013-08-18 14:56:20 +04:00
if (gtk_main_level() > 1) {
/*
* We don't run the callbacks if we're in the middle of a
* subsidiary gtk_main. Instead, ask for a callback when we
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
* get back out of the subsidiary main loop (if we haven't
* already arranged one), so we can reschedule ourself then.
Don't run toplevel callbacks in modal dialogs. Because some of them can call gtk_main_quit(), which completely confuses the dialog box system. [originally from svn r10029]
2013-08-18 14:56:20 +04:00
*/
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
if (!inst->quit_fn_scheduled) {
GTK 3 prep: write a replacement for gtk_quit_add(). GTK 2 has deprecated it and provided no replacement; a bug tracker entry I found on the subject suggested that it was functionality that didn't really belong in GTK, and glib ought to provide a replacement instead, which would be a perfectly fine thing to suggest if they had waited for glib to get round to doing so *before* throwing out a function people were actually using. Sigh. Anyway, it turns out that subsidiary invocations of gtk_main() don't happen inside GTK as far as I can see, so all I need to do is to make sure my own invocations of gtk_main() are followed by a cleanup function which runs any quit functions that I've registered. That was the last deprecated GTK function, so we now build cleanly with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that has migrating to Cairo drawing as a prerequisite.)
2015-08-09 13:33:43 +03:00
request_post_main(inst);
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
inst->quit_fn_scheduled = TRUE;
}
/*
* And unschedule this idle function, since we've now done
* everything we can until the innermost gtk_main has quit and
* can reschedule us with a chance of actually taking action.
*/
if (inst->idle_fn_scheduled) { /* double-check, just in case */
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
g_source_remove(inst->toplevel_callback_idle_id);
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
inst->idle_fn_scheduled = FALSE;
}
Don't run toplevel callbacks in modal dialogs. Because some of them can call gtk_main_quit(), which completely confuses the dialog box system. [originally from svn r10029]
2013-08-18 14:56:20 +04:00
} else {
run_toplevel_callbacks();
}
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 20:06:08 +04:00
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
/*
* If we've emptied our toplevel callback queue, unschedule
* ourself. Otherwise, leave ourselves pending so we'll be called
* again to deal with more callbacks after another round of the
* event loop.
*/
if (!toplevel_callback_pending() && inst->idle_fn_scheduled) {
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
g_source_remove(inst->toplevel_callback_idle_id);
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
inst->idle_fn_scheduled = FALSE;
}
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 20:06:08 +04:00
return TRUE;
}
Don't run toplevel callbacks in modal dialogs. Because some of them can call gtk_main_quit(), which completely confuses the dialog box system. [originally from svn r10029]
2013-08-18 14:56:20 +04:00
static void notify_toplevel_callback(void *frontend)
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 20:06:08 +04:00
{
struct gui_data *inst = (struct gui_data *)frontend;
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
if (!inst->idle_fn_scheduled) {
inst->toplevel_callback_idle_id =
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
g_idle_add(idle_toplevel_callback_func, inst);
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
inst->idle_fn_scheduled = TRUE;
}
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 20:06:08 +04:00
}
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 16:20:21 +03:00
static gint timer_trigger(gpointer data)
{
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-19 01:42:48 +04:00
unsigned long now = GPOINTER_TO_LONG(data);
unsigned long next, then;
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 16:20:21 +03:00
long ticks;
Fix an annoying warning from GTK on Ubuntu 14.04. Timer objects evaporate when our timer_trigger callback is called, and therefore we should not remember their ids beyond that time and attempt to cancel them later. Previous versions of GTK silently ignored us doing that, but upgrading to Ubuntu Trusty has given me a version of GTK that complains about it, so let's stop doing it. [originally from svn r10181]
2014-04-20 20:48:18 +04:00
/*
Another fix to timer handling. Robert de Bath points out that failure to remove the timer whose callback returned FALSE may not have been the cause of runaway timer explosion; another possibility is that a function called from timer_trigger()'s call to run_timers() has already set a timer up by the time run_timers() returns, and then we set another one up on top of it. Fix that too. [originally from svn r10206]
2014-07-13 11:49:29 +04:00
* Destroy the timer we got here on.
Fix an annoying warning from GTK on Ubuntu 14.04. Timer objects evaporate when our timer_trigger callback is called, and therefore we should not remember their ids beyond that time and attempt to cancel them later. Previous versions of GTK silently ignored us doing that, but upgrading to Ubuntu Trusty has given me a version of GTK that complains about it, so let's stop doing it. [originally from svn r10181]
2014-04-20 20:48:18 +04:00
*/
Work around a timer leak with GTK 2.4.22 on openSUSE 13.1. Mihkel Ader reports that on that system, timers apparently aren't getting auto-destroyed when timer_trigger returns FALSE, so the change in r10181 has caused GTK PuTTY to gradually allocate more and more timers and consume more and more CPU as they all keep firing. As far as I can see, this must surely be a bug in GTK 2 (the docs say that timers _are_ auto-destroyed when their callback returns false), and it doesn't seem to happen for me with GTK 2.4.23 on Ubuntu 14.04. However, I'll try to work around it by _explicitly_ destroying each old timer before we zero out the variable containing its id. [originally from svn r10202] [r10181 == e4c4bd20920e11458ab0ec0cd17c69b8bf7f6d00]
2014-07-09 02:22:12 +04:00
if (timer_id) {
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
g_source_remove(timer_id);
Work around a timer leak with GTK 2.4.22 on openSUSE 13.1. Mihkel Ader reports that on that system, timers apparently aren't getting auto-destroyed when timer_trigger returns FALSE, so the change in r10181 has caused GTK PuTTY to gradually allocate more and more timers and consume more and more CPU as they all keep firing. As far as I can see, this must surely be a bug in GTK 2 (the docs say that timers _are_ auto-destroyed when their callback returns false), and it doesn't seem to happen for me with GTK 2.4.23 on Ubuntu 14.04. However, I'll try to work around it by _explicitly_ destroying each old timer before we zero out the variable containing its id. [originally from svn r10202] [r10181 == e4c4bd20920e11458ab0ec0cd17c69b8bf7f6d00]
2014-07-09 02:22:12 +04:00
timer_id = 0;
}
Fix an annoying warning from GTK on Ubuntu 14.04. Timer objects evaporate when our timer_trigger callback is called, and therefore we should not remember their ids beyond that time and attempt to cancel them later. Previous versions of GTK silently ignored us doing that, but upgrading to Ubuntu Trusty has given me a version of GTK that complains about it, so let's stop doing it. [originally from svn r10181]
2014-04-20 20:48:18 +04:00
Another fix to timer handling. Robert de Bath points out that failure to remove the timer whose callback returned FALSE may not have been the cause of runaway timer explosion; another possibility is that a function called from timer_trigger()'s call to run_timers() has already set a timer up by the time run_timers() returns, and then we set another one up on top of it. Fix that too. [originally from svn r10206]
2014-07-13 11:49:29 +04:00
/*
* run_timers() may cause a call to timer_change_notify, in which
* case a new timer will already have been set up and left in
* timer_id. If it hasn't, and run_timers reports that some timing
* still needs to be done, we do it ourselves.
*/
if (run_timers(now, &next) && !timer_id) {
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-19 01:42:48 +04:00
then = now;
now = GETTICKCOUNT();
if (now - then > next - then)
ticks = 0;
else
ticks = next - now;
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
timer_id = g_timeout_add(ticks, timer_trigger, LONG_TO_GPOINTER(next));
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 16:20:21 +03:00
}
/*
Work around a timer leak with GTK 2.4.22 on openSUSE 13.1. Mihkel Ader reports that on that system, timers apparently aren't getting auto-destroyed when timer_trigger returns FALSE, so the change in r10181 has caused GTK PuTTY to gradually allocate more and more timers and consume more and more CPU as they all keep firing. As far as I can see, this must surely be a bug in GTK 2 (the docs say that timers _are_ auto-destroyed when their callback returns false), and it doesn't seem to happen for me with GTK 2.4.23 on Ubuntu 14.04. However, I'll try to work around it by _explicitly_ destroying each old timer before we zero out the variable containing its id. [originally from svn r10202] [r10181 == e4c4bd20920e11458ab0ec0cd17c69b8bf7f6d00]
2014-07-09 02:22:12 +04:00
* Returning FALSE means 'don't call this timer again', which
* _should_ be redundant given that we removed it above, but just
* in case, return FALSE anyway.
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 16:20:21 +03:00
*/
return FALSE;
}
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-19 01:42:48 +04:00
void timer_change_notify(unsigned long next)
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 16:20:21 +03:00
{
long ticks;
if (timer_id)
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
g_source_remove(timer_id);
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 16:20:21 +03:00
ticks = next - GETTICKCOUNT();
if (ticks <= 0)
ticks = 1; /* just in case */
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
timer_id = g_timeout_add(ticks, timer_trigger, LONG_TO_GPOINTER(next));
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 20:45:23 +04:00
}
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#if GTK_CHECK_VERSION(2,0,0)
gboolean fd_input_func(GIOChannel *source, GIOCondition condition,
gpointer data)
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 16:40:05 +04:00
{
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
int sourcefd = g_io_channel_unix_get_fd(source);
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 22:10:25 +04:00
/*
* We must process exceptional notifications before ordinary
* readability ones, or we may go straight past the urgent
* marker.
*/
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
if (condition & G_IO_PRI)
select_result(sourcefd, 4);
if (condition & G_IO_IN)
select_result(sourcefd, 1);
if (condition & G_IO_OUT)
select_result(sourcefd, 2);
return TRUE;
}
#else
void fd_input_func(gpointer data, gint sourcefd, GdkInputCondition condition)
{
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 22:10:25 +04:00
if (condition & GDK_INPUT_EXCEPTION)
select_result(sourcefd, 4);
if (condition & GDK_INPUT_READ)
select_result(sourcefd, 1);
if (condition & GDK_INPUT_WRITE)
select_result(sourcefd, 2);
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 16:40:05 +04:00
}
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#endif
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 16:40:05 +04: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 20:45:23 +04:00
void destroy(GtkWidget *widget, gpointer data)
{
gtk_main_quit();
}
gint focus_event(GtkWidget *widget, GdkEventFocus *event, gpointer data)
{
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)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 22:34:45 +03: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 15:08:59 +04:00
term_update(inst->term);
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 16:58:13 +04:00
show_mouseptr(inst, 1);
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 22:09:42 +04:00
return FALSE;
}
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 20:05:58 +03:00
void set_busy_status(void *frontend, int status)
{
struct gui_data *inst = (struct gui_data *)frontend;
inst->busy_status = status;
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 22:09:42 +04:00
/*
* set or clear the "raw mouse message" mode
*/
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 16:58:13 +04:00
void set_raw_mouse_mode(void *frontend, int 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:52:21 +04:00
activate = activate && !conf_get_int(inst->conf, CONF_no_mouse_rep);
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 14:40:30 +04:00
send_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 20:05:58 +03: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 22:09:42 +04: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 16:58:13 +04:00
void request_resize(void *frontend, 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 20:59:13 +03: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 20:24:42 +04: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.
*/
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 16:58:13 +04:00
get_window_pixels(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 20:24:42 +04: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 22:52:21 +04: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 20:24:42 +04: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 11:59:25 +03: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 22:33:29 +03:00
gtk_window_resize(GTK_WINDOW(inst->window),
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 20:24:42 +04:00
#else
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 23:02:12 +03: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.
*
* 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 22:00:50 +04: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 17:53:43 +03:00
gdk_window_resize(gtk_widget_get_window(inst->window),
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 20:24:42 +04:00
area_x + offset_x, area_y + offset_y);
#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 20:59:13 +03:00
#else /* GTK_CHECK_VERSION(3,0,0) */
/*
* In GTK3, we can do this by using gtk_window_resize_to_geometry,
* which uses the fact that we've already set up the main window's
* WM hints to reflect the terminal drawing area's resize
* increment (i.e. character cell) and the fixed amount of stuff
* round the edges.
*/
gtk_window_resize_to_geometry(GTK_WINDOW(inst->window), w, h);
#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 22:09:42 +04: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 16:58:13 +04:00
static void real_palette_set(struct gui_data *inst, int n, int r, int g, int b)
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04:00
{
inst->cols[n].red = r * 0x0101;
inst->cols[n].green = g * 0x0101;
inst->cols[n].blue = b * 0x0101;
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 16:22:14 +03:00
#if !GTK_CHECK_VERSION(3,0,0)
{
gboolean success[1];
gdk_colormap_free_colors(inst->colmap, inst->cols + n, 1);
gdk_colormap_alloc_colors(inst->colmap, inst->cols + n, 1,
FALSE, TRUE, success);
if (!success[0])
g_error("%s: couldn't allocate colour %d (#%02x%02x%02x)\n",
appname, n, r, g, b);
}
#endif
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04: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 16:11:45 +03:00
void set_gdk_window_background(GdkWindow *win, const GdkColor *col)
{
#if GTK_CHECK_VERSION(3,0,0)
/* gdk_window_set_background is deprecated; work around its
* absence. */
GdkRGBA rgba;
rgba.red = col->red / 65535.0;
rgba.green = col->green / 65535.0;
rgba.blue = col->blue / 65535.0;
rgba.alpha = 1.0;
gdk_window_set_background_rgba(win, &rgba);
#else
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 21:50:23 +03:00
{
/* For GTK1, which doesn't have a 'const' on
* gdk_window_set_background's second parameter type. */
GdkColor col_mutable = *col;
gdk_window_set_background(win, &col_mutable);
}
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 16:11:45 +03:00
#endif
}
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 16:58:13 +04:00
void set_window_background(struct gui_data *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 15:58:59 +04:00
{
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
if (inst->area && gtk_widget_get_window(inst->area))
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 16:11:45 +03:00
set_gdk_window_background(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 17:53:43 +03:00
&inst->cols[258]);
if (inst->window && gtk_widget_get_window(inst->window))
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 16:11:45 +03:00
set_gdk_window_background(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 17:53:43 +03:00
&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 15:58:59 +04: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 16:58:13 +04:00
void palette_set(void *frontend, int n, int r, int g, int b)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
if (n >= 16)
n += 256 - 16;
A collection of small bug fixes from Chris West, apparently spotted by Coverity: assorted language-use goofs like freeing the wrong thing or forgetting to initialise a string on all code paths. [originally from svn r9889]
2013-07-01 21:56:33 +04:00
if (n >= NALLCOLOURS)
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
return;
real_palette_set(inst, n, r, g, b);
Equivalent of r6583 window-border palette-change fix for Gtk. [originally from svn r6609] [r6583 == f9c1d0acf83e8cd73afa905b5d85bcdae9c311eb]
2006-03-13 01:17:46 +03:00
if (n == 258) {
/* Default Background changed. Ensure space between text area and
* window border is redrawn */
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 16:58:13 +04:00
set_window_background(inst);
Equivalent of r6583 window-border palette-change fix for Gtk. [originally from svn r6609] [r6583 == f9c1d0acf83e8cd73afa905b5d85bcdae9c311eb]
2006-03-13 01:17:46 +03:00
draw_backing_rect(inst);
gtk_widget_queue_draw(inst->area);
}
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 22:09:42 +04:00
}
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04: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 16:58:13 +04:00
void palette_reset(void *frontend)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:52:21 +04:00
/* This maps colour indices in inst->conf to those used in inst->cols. */
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04:00
static const int ww[] = {
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
256, 257, 258, 259, 260, 261,
0, 8, 1, 9, 2, 10, 3, 11,
4, 12, 5, 13, 6, 14, 7, 15
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04:00
};
int i;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
assert(lenof(ww) == NCFGCOLOURS);
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04: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 16:22:14 +03:00
#if !GTK_CHECK_VERSION(3,0,0)
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04:00
if (!inst->colmap) {
inst->colmap = gdk_colormap_get_system();
} else {
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
gdk_colormap_free_colors(inst->colmap, inst->cols, NALLCOLOURS);
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04: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 16:22:14 +03:00
#endif
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04:00
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
for (i = 0; i < NCFGCOLOURS; i++) {
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 22:52:21 +04:00
inst->cols[ww[i]].red =
conf_get_int_int(inst->conf, CONF_colours, i*3+0) * 0x0101;
inst->cols[ww[i]].green =
conf_get_int_int(inst->conf, CONF_colours, i*3+1) * 0x0101;
inst->cols[ww[i]].blue =
conf_get_int_int(inst->conf, CONF_colours, i*3+2) * 0x0101;
Support server requests for colour palette changes. [originally from svn r2048]
2002-10-14 14:21:35 +04:00
}
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
for (i = 0; i < NEXTCOLOURS; i++) {
if (i < 216) {
int r = i / 36, g = (i / 6) % 6, b = i % 6;
Fix 256-colours-match-xterm, based on 256colres.pl from xterm-205. Largely untested -- may not even compile on Windows. [originally from svn r6393]
2005-10-14 01:56:43 +04:00
inst->cols[i+16].red = r ? r * 0x2828 + 0x3737 : 0;
inst->cols[i+16].green = g ? g * 0x2828 + 0x3737 : 0;
Fix a stupid one-character typo that was breaking 256-colour support on GTK. [originally from svn r7403]
2007-03-19 15:05:34 +03:00
inst->cols[i+16].blue = b ? b * 0x2828 + 0x3737 : 0;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
} else {
int shade = i - 216;
Fix 256-colours-match-xterm, based on 256colres.pl from xterm-205. Largely untested -- may not even compile on Windows. [originally from svn r6393]
2005-10-14 01:56:43 +04:00
shade = shade * 0x0a0a + 0x0808;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
inst->cols[i+16].red = inst->cols[i+16].green =
inst->cols[i+16].blue = shade;
}
}
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 16:22:14 +03:00
#if !GTK_CHECK_VERSION(3,0,0)
{
gboolean success[NALLCOLOURS];
gdk_colormap_alloc_colors(inst->colmap, inst->cols, NALLCOLOURS,
FALSE, TRUE, success);
for (i = 0; i < NALLCOLOURS; i++) {
if (!success[i])
g_error("%s: couldn't allocate colour %d (#%02x%02x%02x)\n",
appname, i,
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 14:21:35 +04: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 16:22:14 +03: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 15:58:59 +04:00
Equivalent of r6583 window-border palette-change fix for Gtk. [originally from svn r6609] [r6583 == f9c1d0acf83e8cd73afa905b5d85bcdae9c311eb]
2006-03-13 01:17:46 +03:00
/* Since Default Background may have changed, ensure that space
* between text area and window border is refreshed. */
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 16:58:13 +04:00
set_window_background(inst);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
if (inst->area && gtk_widget_get_window(inst->area)) {
Equivalent of r6583 window-border palette-change fix for Gtk. [originally from svn r6609] [r6583 == f9c1d0acf83e8cd73afa905b5d85bcdae9c311eb]
2006-03-13 01:17:46 +03:00
draw_backing_rect(inst);
gtk_widget_queue_draw(inst->area);
}
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 22:09:42 +04: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 22:07:27 +04:00
/* Ensure that all the cut buffers exist - according to the ICCCM, we must
* do this before we start using cut buffers.
*/
void init_cutbuffers()
{
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 18:35:19 +03:00
#ifndef NOT_X_WINDOWS
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
unsigned char empty[] = "";
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER0, XA_STRING, 8, PropModeAppend, empty, 0);
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER1, XA_STRING, 8, PropModeAppend, empty, 0);
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER2, XA_STRING, 8, PropModeAppend, empty, 0);
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER3, XA_STRING, 8, PropModeAppend, empty, 0);
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER4, XA_STRING, 8, PropModeAppend, empty, 0);
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER5, XA_STRING, 8, PropModeAppend, empty, 0);
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER6, XA_STRING, 8, PropModeAppend, empty, 0);
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
XA_CUT_BUFFER7, XA_STRING, 8, PropModeAppend, empty, 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 18:35:19 +03: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 22:07:27 +04:00
}
/* Store the data in a cut-buffer. */
void store_cutbuffer(char * ptr, int 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 18:35:19 +03:00
#ifndef NOT_X_WINDOWS
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
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 22:07:27 +04:00
/* ICCCM says we must rotate the buffers before storing to buffer 0. */
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
XRotateBuffers(disp, 1);
XStoreBytes(disp, ptr, 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 18:35:19 +03: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 22:07:27 +04:00
}
/* Retrieve data from a cut-buffer.
* Returned data needs to be freed with XFree().
*/
char * retrieve_cutbuffer(int * nbytes)
{
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 18:35:19 +03:00
#ifndef NOT_X_WINDOWS
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
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 22:07:27 +04:00
char * ptr;
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
ptr = XFetchBytes(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 15:30:15 +04:00
if (*nbytes <= 0 && 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 22:07:27 +04:00
XFree(ptr);
ptr = 0;
}
return ptr;
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 18:35:19 +03:00
#else
return NULL;
#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 22:07:27 +04:00
}
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-14 01:18:17 +03:00
void write_clip(void *frontend, wchar_t * data, int *attr, int len, int 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 15:24:25 +04:00
if (inst->pasteout_data)
sfree(inst->pasteout_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 23:57:17 +04:00
if (inst->pasteout_data_ctext)
sfree(inst->pasteout_data_ctext);
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 15:20:34 +03:00
if (inst->pasteout_data_utf8)
sfree(inst->pasteout_data_utf8);
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-02 01:25:25 +03: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 23:57:17 +04: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-02 01:25:25 +03: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 19:17:56 +03:00
if (!inst->direct_to_font) {
Add some missing consts in character set handling. [originally from svn r9291]
2011-09-16 23:18:52 +04:00
const wchar_t *tmp = 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 15:20:34 +03:00
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 18:35:19 +03: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 23:57:17 +04:00
XTextProperty tp;
char *list[1];
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
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 18:35:19 +03:00
#endif
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-02 01:25:25 +03:00
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
inst->pasteout_data_utf8 = snewn(len*6, char);
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-02 01:25:25 +03:00
inst->pasteout_data_utf8_len = len*6;
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 15:20:34 +03:00
inst->pasteout_data_utf8_len =
charset_from_unicode(&tmp, &tmplen, inst->pasteout_data_utf8,
inst->pasteout_data_utf8_len,
CS_UTF8, NULL, NULL, 0);
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 19:17:56 +03:00
if (inst->pasteout_data_utf8_len == 0) {
sfree(inst->pasteout_data_utf8);
inst->pasteout_data_utf8 = NULL;
} else {
inst->pasteout_data_utf8 =
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
sresize(inst->pasteout_data_utf8,
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 23:57:17 +04:00
inst->pasteout_data_utf8_len + 1, char);
inst->pasteout_data_utf8[inst->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 18:35:19 +03: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 23:57:17 +04:00
list[0] = inst->pasteout_data_utf8;
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
if (Xutf8TextListToTextProperty(disp, list, 1,
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 23:57:17 +04:00
XCompoundTextStyle, &tp) == 0) {
inst->pasteout_data_ctext = snewn(tp.nitems+1, char);
memcpy(inst->pasteout_data_ctext, tp.value, tp.nitems);
inst->pasteout_data_ctext_len = tp.nitems;
XFree(tp.value);
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 18:35:19 +03:00
} else
#endif
{
Fix double-free in X selection code. [originally from svn r4367]
2004-07-27 19:20:37 +04:00
inst->pasteout_data_ctext = NULL;
inst->pasteout_data_ctext_len = 0;
}
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-02 01:25:25 +03:00
} else {
inst->pasteout_data_utf8 = NULL;
inst->pasteout_data_utf8_len = 0;
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 23:57:17 +04:00
inst->pasteout_data_ctext = NULL;
inst->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 15:20:34 +03:00
}
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
inst->pasteout_data = snewn(len*6, char);
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 19:17:56 +03:00
inst->pasteout_data_len = len*6;
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 21:28:23 +03:00
inst->pasteout_data_len = wc_to_mb(inst->ucsdata.line_codepage, 0,
data, len, inst->pasteout_data,
inst->pasteout_data_len,
NULL, NULL, NULL);
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 19:17:56 +03:00
if (inst->pasteout_data_len == 0) {
sfree(inst->pasteout_data);
inst->pasteout_data = NULL;
} else {
inst->pasteout_data =
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
sresize(inst->pasteout_data, inst->pasteout_data_len, char);
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 19:17:56 +03: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 15:24:25 +04: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 22:07:27 +04:00
store_cutbuffer(inst->pasteout_data, inst->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 15:24:25 +04:00
if (gtk_selection_owner_set(inst->area, GDK_SELECTION_PRIMARY,
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 22:03:06 +04: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 03:06:38 +03:00
#if GTK_CHECK_VERSION(2,0,0)
Add missing call to gtk_selection_clear_targets(), without which the list of selection targets offered by GTK PuTTY/pterm grows an extra copy of each of the three supported text formats every time the user makes a selection! [originally from svn r8364]
2008-12-02 02:03:11 +03:00
gtk_selection_clear_targets(inst->area, GDK_SELECTION_PRIMARY);
gtk_selection_clear_targets() does not exist on GTK 1, so ifdef it. [originally from svn r8371]
2008-12-03 03:06:38 +03: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 15:24:25 +04:00
gtk_selection_add_target(inst->area, GDK_SELECTION_PRIMARY,
GDK_SELECTION_TYPE_STRING, 1);
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 23:57:17 +04:00
if (inst->pasteout_data_ctext)
gtk_selection_add_target(inst->area, GDK_SELECTION_PRIMARY,
compound_text_atom, 1);
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-02 01:25:25 +03:00
if (inst->pasteout_data_utf8)
gtk_selection_add_target(inst->area, GDK_SELECTION_PRIMARY,
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 21:40:52 +04:00
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 15:24:25 +04: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 22:10:13 +04:00
if (must_deselect)
term_deselect(inst->term);
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 15:24:25 +04:00
}
void selection_get(GtkWidget *widget, GtkSelectionData *seldata,
guint info, guint time_stamp, gpointer data)
{
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)data;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
GdkAtom target = gtk_selection_data_get_target(seldata);
if (target == utf8_string_atom)
gtk_selection_data_set(seldata, target, 8,
(unsigned char *)inst->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 15:20:34 +03:00
inst->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 17:53:43 +03:00
else if (target == compound_text_atom)
gtk_selection_data_set(seldata, target, 8,
(unsigned char *)inst->pasteout_data_ctext,
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 23:57:17 +04:00
inst->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 15:20:34 +03:00
else
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gtk_selection_data_set(seldata, target, 8,
(unsigned char *)inst->pasteout_data,
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-31 02:00:14 +03:00
inst->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 15:24:25 +04:00
}
gint selection_clear(GtkWidget *widget, GdkEventSelection *seldata,
gpointer data)
{
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)data;
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 22:03:06 +04:00
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 15:08:59 +04:00
term_deselect(inst->term);
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 15:24:25 +04:00
if (inst->pasteout_data)
sfree(inst->pasteout_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 23:57:17 +04:00
if (inst->pasteout_data_ctext)
sfree(inst->pasteout_data_ctext);
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 15:20:34 +03:00
if (inst->pasteout_data_utf8)
sfree(inst->pasteout_data_utf8);
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 15:24:25 +04:00
inst->pasteout_data = NULL;
inst->pasteout_data_len = 0;
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 23:57:17 +04:00
inst->pasteout_data_ctext = NULL;
inst->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 15:20:34 +03:00
inst->pasteout_data_utf8 = NULL;
inst->pasteout_data_utf8_len = 0;
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 15:24:25 +04:00
return TRUE;
}
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 16:58:13 +04:00
void request_paste(void *frontend)
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 15:24:25 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 15:24:25 +04: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 15:20:34 +03: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 19:17:56 +03:00
if (!inst->direct_to_font) {
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-02 01:25:25 +03: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, GDK_SELECTION_PRIMARY,
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 22:03:06 +04:00
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-02 01:25:25 +03:00
} else {
/*
* 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, GDK_SELECTION_PRIMARY,
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 22:03:06 +04: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-02 01:25:25 +03: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 15:24:25 +04:00
}
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-15 03:32:00 +04:00
gint idle_paste_func(gpointer data); /* forward ref */
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 15:24:25 +04:00
void selection_received(GtkWidget *widget, GtkSelectionData *seldata,
First bug discovered as a result of global-removal: pasting into pterm caused a crash because I had the wrong prototype for the selection_received event handler. Should be fixed. [originally from svn r2150]
2002-10-28 12:38:28 +03:00
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 15:24:25 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)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 23:57:17 +04: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 18:35:19 +03:00
int length;
#ifndef NOT_X_WINDOWS
char **list;
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 23:57:17 +04:00
int free_list_required = 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 22:07:27 +04:00
int free_required = 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 18:35:19 +03: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 23:57:17 +04: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 17:53:43 +03: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);
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 16:58:13 +04:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
if (seldata_target == utf8_string_atom && seldata_length <= 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 15:20:34 +03:00
/*
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 22:43:30 +04:00
* Failed to get a UTF-8 selection string. Try compound
* text next.
*/
gtk_selection_convert(inst->area, GDK_SELECTION_PRIMARY,
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 22:03:06 +04:00
compound_text_atom,
inst->input_event_time);
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 22:43:30 +04:00
return;
}
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
if (seldata_target == compound_text_atom && seldata_length <= 0) {
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 22:43:30 +04:00
/*
* Failed to get UTF-8 or compound text. Try an ordinary
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 15:20:34 +03:00
* string.
*/
gtk_selection_convert(inst->area, GDK_SELECTION_PRIMARY,
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 22:03:06 +04:00
GDK_SELECTION_TYPE_STRING,
inst->input_event_time);
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 15:20:34 +03:00
return;
}
/*
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 22:07:27 +04: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 15:20:34 +03:00
*/
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
if (seldata_length > 0 &&
seldata_type != GDK_SELECTION_TYPE_STRING &&
seldata_type != compound_text_atom &&
seldata_type != utf8_string_atom)
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 22:07:27 +04:00
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 23:57:17 +04: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 22:07:27 +04: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 17:53:43 +03: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 18:35:19 +03: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 22:07:27 +04:00
text = retrieve_cutbuffer(&length);
if (length == 0)
return;
/* Xterm is rumoured to expect Latin-1, though I havn't checked the
* source, so use that as a de-facto standard. */
charset = CS_ISO8859_1;
free_required = 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 18:35:19 +03: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 22:07:27 +04:00
} else {
Fix indentation after Richard B's patch in rev 1.137 [r3409]. [originally from svn r4241] [r3409 == 7798a59987c84edaa6f1bd5f52ac9aa93b7eb417]
2004-05-22 18:21:27 +04:00
/*
* Convert COMPOUND_TEXT into UTF-8.
*/
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
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 18:35:19 +03:00
#ifndef NOT_X_WINDOWS
XTextProperty tp;
int ret, count;
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
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 18:35:19 +03:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
tp.value = (unsigned char *)seldata_data;
tp.encoding = (Atom) seldata_type;
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 18:35:19 +03:00
tp.format = gtk_selection_data_get_format(seldata);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
tp.nitems = seldata_length;
Replace deprecated GDK_DISPLAY() with modern facilities. We still don't actually support more than one X display active at once, so it's sufficient to replace every call to that macro with GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
2015-08-16 11:23:32 +03:00
ret = Xutf8TextPropertyToTextList(disp, &tp, &list, &count);
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 18:35:19 +03:00
if (ret == 0 && count == 1) {
text = list[0];
length = strlen(list[0]);
charset = CS_UTF8;
free_list_required = 1;
} else
#endif
{
Fix indentation after Richard B's patch in rev 1.137 [r3409]. [originally from svn r4241] [r3409 == 7798a59987c84edaa6f1bd5f52ac9aa93b7eb417]
2004-05-22 18:21:27 +04:00
/*
* Compound text failed; fall back to STRING.
*/
gtk_selection_convert(inst->area, GDK_SELECTION_PRIMARY,
GDK_SELECTION_TYPE_STRING,
inst->input_event_time);
return;
}
} else {
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
text = (char *)seldata_data;
length = seldata_length;
charset = (seldata_type == utf8_string_atom ?
Fix indentation after Richard B's patch in rev 1.137 [r3409]. [originally from svn r4241] [r3409 == 7798a59987c84edaa6f1bd5f52ac9aa93b7eb417]
2004-05-22 18:21:27 +04:00
CS_UTF8 : inst->ucsdata.line_codepage);
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 23:57:17 +04: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 22:07:27 +04: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 23:57:17 +04: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 15:24:25 +04:00
if (inst->pastein_data)
sfree(inst->pastein_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 23:57:17 +04:00
inst->pastein_data = snewn(length, wchar_t);
inst->pastein_data_len = length;
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 15:20:34 +03:00
inst->pastein_data_len =
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 23:57:17 +04:00
mb_to_wc(charset, 0, text, length,
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 15:20:34 +03:00
inst->pastein_data, inst->pastein_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 15:24:25 +04:00
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 15:08:59 +04:00
term_do_paste(inst->term);
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-15 03:32:00 +04: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 18:35:19 +03: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 23:57:17 +04:00
if (free_list_required)
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 22:07:27 +04:00
if (free_required)
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 18:35:19 +03: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-15 03:32:00 +04: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 16:58:13 +04:00
void get_clip(void *frontend, wchar_t ** p, int *len)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:09:42 +04:00
if (p) {
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 15:24:25 +04:00
*p = inst->pastein_data;
*len = inst->pastein_data_len;
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 22:09:42 +04:00
}
}
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 17:55:47 +04:00
static void set_window_titles(struct gui_data *inst)
{
/*
* 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);
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 22:52:21 +04:00
if (!conf_get_int(inst->conf, CONF_win_name_always))
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
gdk_window_set_icon_name(gtk_widget_get_window(inst->window),
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 17:55:47 +04: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 16:58:13 +04:00
void set_title(void *frontend, char *title)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:52:21 +04:00
sfree(inst->wintitle);
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 17:55:47 +04: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 22:09:42 +04: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 16:58:13 +04:00
void set_icon(void *frontend, char *title)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:52:21 +04:00
sfree(inst->icontitle);
inst->icontitle = dupstr(title);
set_window_titles(inst);
}
void set_title_and_icon(void *frontend, char *title, char *icon)
{
struct gui_data *inst = (struct gui_data *)frontend;
sfree(inst->wintitle);
inst->wintitle = dupstr(title);
sfree(inst->icontitle);
inst->icontitle = dupstr(icon);
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 17:55:47 +04: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 22:09:42 +04: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 16:58:13 +04:00
void set_sbar(void *frontend, 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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 22:52:21 +04:00
if (!conf_get_int(inst->conf, CONF_scrollbar))
Richard's patch to make the scrollbar configurably absent. (Still want a new option to configure it to be on the LHS though. And some lunatic is bound to ask for an xterm-style scrollbar too... :-) [originally from svn r2062]
2002-10-15 18:55:19 +04:00
return;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03: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);
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 16:44:01 +04:00
inst->ignore_sbar = TRUE;
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
gtk_adjustment_changed(inst->sbar_adjust);
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 16:44:01 +04:00
inst->ignore_sbar = FALSE;
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
}
void scrollbar_moved(GtkAdjustment *adj, gpointer data)
{
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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)data;
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 22:52:21 +04:00
if (!conf_get_int(inst->conf, CONF_scrollbar))
Richard's patch to make the scrollbar configurably absent. (Still want a new option to configure it to be on the LHS though. And some lunatic is bound to ask for an xterm-style scrollbar too... :-) [originally from svn r2062]
2002-10-15 18:55:19 +04: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 16:44:01 +04:00
if (!inst->ignore_sbar)
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03: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 22:09:42 +04: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 16:58:13 +04:00
void sys_cursor(void *frontend, 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 22:09:42 +04: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-29 00:58:07 +03: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).
*/
A few small changes to make the PuTTY source base more usable as a basis for other terminal-involving applications: a stub implementation of the printing interface, an additional function in notiming.c, and also I've renamed the front-end function beep() to do_beep() so as not to clash with beep() in lib[n]curses. [originally from svn r6479]
2005-12-09 23:04:19 +03:00
void do_beep(void *frontend, 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 22:09:42 +04:00
{
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 16:36:11 +03:00
if (mode == BELL_DEFAULT)
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-29 00:58:07 +03:00
gdk_beep();
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 22:09:42 +04:00
}
Rename CharWidth() to char_width(). The former name clashes with an API function in Mac OS. [originally from svn r2205]
2002-11-10 00:46:21 +03:00
int char_width(Context ctx, 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 22:09:42 +04:00
{
/*
* Under X, any fixed-width font really _is_ fixed-width.
* Double-width characters will be dealt with using a separate
* font. For the moment we can simply return 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 14:40:23 +03:00
*
* FIXME: but is that also true of Pango?
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 22:09:42 +04:00
*/
return 1;
}
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 16:58:13 +04:00
Context get_ctx(void *frontend)
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 22:09:42 +04: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 16:58:13 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
struct draw_ctx *dctx;
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 11:02:31 +03:00
GdkWindow *target;
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 16:58:13 +04:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
if (!gtk_widget_get_window(inst->area))
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 14:40:30 +04:00
return NULL;
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 16:58:13 +04: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 11:02:31 +03:00
#ifndef NO_BACKING_PIXMAPS
target = inst->pixmap;
#else
target = gtk_widget_get_window(inst->area);
#endif
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
dctx = snew(struct draw_ctx);
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 16:58:13 +04:00
dctx->inst = 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 23:05:56 +03:00
dctx->uctx.type = inst->drawtype;
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_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 11:02:31 +03:00
dctx->uctx.u.gdk.target = 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 23:05:56 +03:00
dctx->uctx.u.gdk.gc = gdk_gc_new(gtk_widget_get_window(inst->area));
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
dctx->uctx.u.cairo.widget = GTK_WIDGET(inst->area);
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 11:02:31 +03:00
dctx->uctx.u.cairo.cr = gdk_cairo_create(target);
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 16:34:19 +03:00
cairo_setup_dctx(dctx);
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 23:05:56 +03:00
}
#endif
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 16:58:13 +04:00
return dctx;
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 22:09:42 +04:00
}
void free_ctx(Context ctx)
{
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 16:58:13 +04:00
struct draw_ctx *dctx = (struct draw_ctx *)ctx;
/* struct gui_data *inst = dctx->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 23:05:56 +03:00
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_GDK) {
gdk_gc_unref(dctx->uctx.u.gdk.gc);
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
cairo_destroy(dctx->uctx.u.cairo.cr);
}
#endif
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 16:58:13 +04:00
sfree(dctx);
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 22:09:42 +04: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 23:05:56 +03:00
static void draw_update(struct draw_ctx *dctx, int x, int y, int w, int h)
{
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 11:02:31 +03:00
#ifndef NO_BACKING_PIXMAPS
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 23:05:56 +03:00
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_GDK) {
gdk_draw_pixmap(gtk_widget_get_window(dctx->inst->area),
dctx->uctx.u.gdk.gc, dctx->inst->pixmap,
x, y, x, y, w, h);
}
#endif
#ifdef DRAW_TEXT_CAIRO /* FIXME: and not GTK3 where a cairo_t is all we have */
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
GdkGC *gc = gdk_gc_new(gtk_widget_get_window(dctx->inst->area));
gdk_draw_pixmap(gtk_widget_get_window(dctx->inst->area),
gc, dctx->inst->pixmap, x, y, x, y, w, h);
gdk_gc_unref(gc);
}
#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 11:02:31 +03:00
#endif
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 23:05:56 +03:00
}
static void draw_set_colour(struct draw_ctx *dctx, int col)
{
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_GDK) {
gdk_gc_set_foreground(dctx->uctx.u.gdk.gc, &dctx->inst->cols[col]);
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
cairo_set_source_rgb(dctx->uctx.u.cairo.cr,
dctx->inst->cols[col].red / 65535.0,
dctx->inst->cols[col].green / 65535.0,
dctx->inst->cols[col].blue / 65535.0);
}
#endif
}
static void draw_rectangle(struct draw_ctx *dctx, int filled,
int x, int y, int w, int h)
{
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_GDK) {
gdk_draw_rectangle(dctx->uctx.u.gdk.target, dctx->uctx.u.gdk.gc,
filled, x, y, w, h);
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
cairo_new_path(dctx->uctx.u.cairo.cr);
if (filled) {
cairo_rectangle(dctx->uctx.u.cairo.cr, x, y, w, h);
cairo_fill(dctx->uctx.u.cairo.cr);
} else {
cairo_rectangle(dctx->uctx.u.cairo.cr,
x + 0.5, y + 0.5, w, h);
cairo_close_path(dctx->uctx.u.cairo.cr);
cairo_stroke(dctx->uctx.u.cairo.cr);
}
}
#endif
}
static void draw_clip(struct draw_ctx *dctx, int x, int y, int w, int h)
{
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_GDK) {
GdkRectangle r;
r.x = x;
r.y = y;
r.width = w;
r.height = h;
gdk_gc_set_clip_rectangle(dctx->uctx.u.gdk.gc, &r);
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
cairo_reset_clip(dctx->uctx.u.cairo.cr);
cairo_new_path(dctx->uctx.u.cairo.cr);
cairo_rectangle(dctx->uctx.u.cairo.cr, x, y, w, h);
cairo_clip(dctx->uctx.u.cairo.cr);
}
#endif
}
static void draw_point(struct draw_ctx *dctx, int x, int y)
{
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_GDK) {
gdk_draw_point(dctx->uctx.u.gdk.target, dctx->uctx.u.gdk.gc, x, y);
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
cairo_new_path(dctx->uctx.u.cairo.cr);
cairo_rectangle(dctx->uctx.u.cairo.cr, x, y, 1, 1);
cairo_fill(dctx->uctx.u.cairo.cr);
}
#endif
}
static void draw_line(struct draw_ctx *dctx, int x0, int y0, int x1, int y1)
{
#ifdef DRAW_TEXT_GDK
if (dctx->uctx.type == DRAWTYPE_GDK) {
gdk_draw_line(dctx->uctx.u.gdk.target, dctx->uctx.u.gdk.gc,
x0, y0, x1, y1);
}
#endif
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
cairo_new_path(dctx->uctx.u.cairo.cr);
cairo_move_to(dctx->uctx.u.cairo.cr, x0 + 0.5, y0 + 0.5);
cairo_line_to(dctx->uctx.u.cairo.cr, x1 + 0.5, y1 + 0.5);
cairo_stroke(dctx->uctx.u.cairo.cr);
}
#endif
}
static void draw_stretch_before(struct draw_ctx *dctx, int x, int y,
int w, int wdouble,
int h, int hdouble, int hbothalf)
{
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
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;
}
cairo_transform(dctx->uctx.u.cairo.cr, &matrix);
}
#endif
}
static void draw_stretch_after(struct draw_ctx *dctx, int x, int y,
int w, int wdouble,
int h, int hdouble, int hbothalf)
{
#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 11:02:31 +03:00
#ifndef NO_BACKING_PIXMAPS
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 23:05:56 +03:00
if (dctx->uctx.type == DRAWTYPE_GDK) {
/*
* 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;
if (wdouble) {
for (i = 0; i < w; i++) {
gdk_draw_pixmap(dctx->uctx.u.gdk.target,
dctx->uctx.u.gdk.gc,
dctx->uctx.u.gdk.target,
x + 2*i, y,
x + 2*i+1, y,
w - i, h);
}
w *= 2;
}
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(dctx->uctx.u.gdk.target,
dctx->uctx.u.gdk.gc,
dctx->uctx.u.gdk.target,
x, y + dt*i + db,
x, y + dt*(i+1),
w, h-i-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 11:02:31 +03: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 23:05:56 +03: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 11:02:31 +03: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 23:05:56 +03:00
#ifdef DRAW_TEXT_CAIRO
if (dctx->uctx.type == DRAWTYPE_CAIRO) {
cairo_set_matrix(dctx->uctx.u.cairo.cr,
&dctx->uctx.u.cairo.origmatrix);
}
#endif
}
static void draw_backing_rect(struct gui_data *inst)
{
struct draw_ctx *dctx = get_ctx(inst);
draw_set_colour(dctx, 258);
draw_rectangle(dctx, 1, 0, 0,
inst->width * inst->font_width + 2*inst->window_border,
inst->height * inst->font_height + 2*inst->window_border);
free_ctx(dctx);
}
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 22:09:42 +04: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'.
*/
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 15:50:16 +04:00
void do_text_internal(Context ctx, int x, int y, wchar_t *text, int len,
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
unsigned long attr, int lattr)
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 22:09:42 +04: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 16:58:13 +04:00
struct draw_ctx *dctx = (struct draw_ctx *)ctx;
struct gui_data *inst = dctx->inst;
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 20:42:43 +04:00
int ncombining, combining;
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 14:40:23 +03:00
int nfg, nbg, t, fontid, shadow, rlen, widefactor, bold;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 17:53:43 +03:00
int monochrome =
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 14:40:30 +04: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 20:42:43 +04:00
if (attr & TATTR_COMBINING) {
ncombining = len;
len = 1;
} else
ncombining = 1;
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-28 01:09:45 +04: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-28 01:42:51 +04:00
if (!!(attr & ATTR_REVERSE) ^ (monochrome && (attr & TATTR_ACTCURS))) {
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 14:40:30 +04:00
t = nfg;
nfg = nbg;
nbg = t;
}
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 19:09:22 +04:00
if ((inst->bold_style & 2) && (attr & ATTR_BOLD)) {
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
if (nfg < 16) nfg |= 8;
else if (nfg >= 256) nfg |= 1;
}
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 19:09:22 +04:00
if ((inst->bold_style & 2) && (attr & ATTR_BLINK)) {
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
if (nbg < 16) nbg |= 8;
else if (nbg >= 256) nbg |= 1;
}
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-28 01:42:51 +04:00
if ((attr & TATTR_ACTCURS) && !monochrome) {
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
nfg = 260;
nbg = 261;
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 14:40:30 +04:00
}
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 22:42:48 +04:00
fontid = shadow = 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-02 00:53:22 +03:00
if (attr & ATTR_WIDE) {
widefactor = 2;
fontid |= 2;
} else {
widefactor = 1;
}
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 19:09:22 +04:00
if ((attr & ATTR_BOLD) && (inst->bold_style & 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 14:40:23 +03:00
bold = 1;
fontid |= 1;
} else {
bold = 0;
}
if (!inst->fonts[fontid]) {
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 22:42:48 +04: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 15:50:16 +04:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Support for line attributes: ESC #3, #4 and #6 for double-width and double-height text. [originally from svn r2054]
2002-10-15 04:22:48 +04:00
x *= 2;
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 15:08:59 +04:00
if (x >= inst->term->cols)
Trim wide text properly at the RH edge of the screen. [originally from svn r2055]
2002-10-15 13:30:16 +04:00
return;
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-02 00:53:22 +03:00
if (x + len*2*widefactor > inst->term->cols)
len = (inst->term->cols-x)/2/widefactor;/* trim to LH half */
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 19:16:35 +03:00
rlen = len * 2;
} else
rlen = len;
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 10:55:04 +03:00
draw_clip(dctx,
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 23:05:56 +03:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
draw_stretch_before(dctx,
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
rlen*widefactor*inst->font_width, TRUE,
inst->font_height,
((lattr & LATTR_MODE) != LATTR_WIDE),
((lattr & LATTR_MODE) == LATTR_BOT));
}
draw_set_colour(dctx, nbg);
draw_rectangle(dctx, TRUE,
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
rlen*widefactor*inst->font_width, inst->font_height);
draw_set_colour(dctx, nfg);
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 23:18:53 +04:00
for (combining = 0; combining < ncombining; combining++) {
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 23:05:56 +03:00
unifont_draw_text(&dctx->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 23:18:53 +04:00
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border+inst->fonts[0]->ascent,
text + combining, len, widefactor > 1,
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 15:20:34 +03: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 14:40:30 +04:00
if (attr & ATTR_UNDER) {
int uheight = inst->fonts[0]->ascent + 1;
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 18:42:56 +04:00
if (uheight >= inst->font_height)
uheight = inst->font_height - 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 23:05:56 +03:00
draw_line(dctx, x*inst->font_width+inst->window_border,
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);
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 14:40:30 +04: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 15:50:16 +04:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
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 23:05:56 +03:00
draw_stretch_after(dctx,
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
rlen*widefactor*inst->font_width, TRUE,
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 22:18:25 +04: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 15:50:16 +04:00
void do_text(Context ctx, int x, int y, wchar_t *text, int len,
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
unsigned long attr, int lattr)
{
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 16:58:13 +04:00
struct draw_ctx *dctx = (struct draw_ctx *)ctx;
struct gui_data *inst = dctx->inst;
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-02 00:53:22 +03:00
int widefactor;
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
do_text_internal(ctx, x, y, text, len, attr, lattr);
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-02 00:53:22 +03:00
if (attr & ATTR_WIDE) {
widefactor = 2;
} else {
widefactor = 1;
}
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 15:50:16 +04:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
x *= 2;
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 15:08:59 +04:00
if (x >= inst->term->cols)
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
return;
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-02 00:53:22 +03:00
if (x + len*2*widefactor > inst->term->cols)
len = (inst->term->cols-x)/2/widefactor;/* trim to LH half */
Support for line attributes: ESC #3, #4 and #6 for double-width and double-height text. [originally from svn r2054]
2002-10-15 04:22:48 +04:00
len *= 2;
}
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 23:05:56 +03:00
draw_update(dctx,
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 22:09:42 +04: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 15:50:16 +04:00
void do_cursor(Context ctx, int x, int y, wchar_t *text, int len,
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 22:09:42 +04:00
unsigned long attr, int lattr)
{
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 16:58:13 +04:00
struct draw_ctx *dctx = (struct draw_ctx *)ctx;
struct gui_data *inst = dctx->inst;
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-29 00:42:39 +04:00
int active, passive, 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 14:40:30 +04: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 22:09:42 +04:00
if (attr & TATTR_PASCURS) {
attr &= ~TATTR_PASCURS;
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 14:40:30 +04:00
passive = 1;
} else
passive = 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 22:52:21 +04:00
if ((attr & TATTR_ACTCURS) && inst->cursor_type != 0) {
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
attr &= ~TATTR_ACTCURS;
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-29 00:42:39 +04:00
active = 1;
} else
active = 0;
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
do_text_internal(ctx, x, y, text, len, attr, lattr);
Fix cursor display on a combined character cell. [originally from svn r4625]
2004-10-15 12:51:57 +04:00
if (attr & TATTR_COMBINING)
len = 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-02 00:53:22 +03:00
if (attr & ATTR_WIDE) {
widefactor = 2;
} else {
widefactor = 1;
}
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 15:50:16 +04:00
if ((lattr & LATTR_MODE) != LATTR_NORM) {
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
x *= 2;
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 15:08:59 +04:00
if (x >= inst->term->cols)
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
return;
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-02 00:53:22 +03:00
if (x + len*2*widefactor > inst->term->cols)
len = (inst->term->cols-x)/2/widefactor;/* trim to LH half */
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
len *= 2;
}
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 22:52:21 +04:00
if (inst->cursor_type == 0) {
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04: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) {
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 23:05:56 +03:00
draw_set_colour(dctx, 261);
draw_rectangle(dctx, FALSE,
x*inst->font_width+inst->window_border,
y*inst->font_height+inst->window_border,
len*widefactor*inst->font_width-1,
inst->font_height-1);
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
}
} else {
int uheight;
int startx, starty, dx, dy, length, i;
int char_width;
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 15:50:16 +04:00
if ((attr & ATTR_WIDE) || (lattr & LATTR_MODE) != LATTR_NORM)
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
char_width = 2*inst->font_width;
else
char_width = inst->font_width;
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 22:52:21 +04:00
if (inst->cursor_type == 1) {
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
uheight = inst->fonts[0]->ascent + 1;
if (uheight >= inst->font_height)
uheight = inst->font_height - 1;
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 22:52:21 +04:00
startx = x * inst->font_width + inst->window_border;
starty = y * inst->font_height + inst->window_border + uheight;
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
dx = 1;
dy = 0;
And fix _cursor_ display on double-width double-width characters (as it were). [originally from svn r4637]
2004-10-15 16:25:51 +04:00
length = len * widefactor * char_width;
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
} else {
int xadjust = 0;
if (attr & TATTR_RIGHTCURS)
xadjust = char_width - 1;
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 22:52:21 +04:00
startx = x * inst->font_width + inst->window_border + xadjust;
starty = y * inst->font_height + inst->window_border;
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
dx = 0;
dy = 1;
length = 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 23:05:56 +03:00
draw_set_colour(dctx, 261);
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
if (passive) {
for (i = 0; i < length; i++) {
if (i % 2 == 0) {
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 23:05:56 +03:00
draw_point(dctx, startx, starty);
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04:00
}
startx += dx;
starty += dy;
}
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-29 00:42:39 +04:00
} else if (active) {
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 23:05:56 +03:00
draw_line(dctx, startx, starty,
startx + (length-1) * dx, starty + (length-1) * dy);
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-29 00:42:39 +04: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 14:40:30 +04:00
}
Support underline and vertical-line cursors as well as block. [originally from svn r2075]
2002-10-15 22:18:25 +04: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 23:05:56 +03:00
draw_update(dctx,
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 11:26:23 +04: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 22:09:42 +04: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 16:58:13 +04:00
GdkCursor *make_mouse_ptr(struct gui_data *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 16:17:03 +04: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 23:07:35 +03: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 13:58:27 +04: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 16:17:03 +04: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 23:07:35 +03: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 16:17:03 +04: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 13:15:42 +03: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 22:09:42 +04: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 20:45:23 +04: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 13:15:42 +03:00
void cmdline_error(const char *p, ...)
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
{
va_list ap;
All the stderr messages in this file now use appname rather than guessing wrongly. [originally from svn r3089]
2003-04-10 15:57:11 +04:00
fprintf(stderr, "%s: ", appname);
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
va_start(ap, p);
vfprintf(stderr, p, ap);
va_end(ap);
fputc('\n', stderr);
exit(1);
}
Stop using GTK3-deprecated gdk_get_display(). The new way is gdk_display_get_name(gdk_display_get_default()), which returns a const char * rather than a char *, so I've also had to fiddle with the prototype and call sites of get_x_display(). (Also included gtkcompat.h into uxputty.c, since that wanted to call gdk_get_display() but didn't previously include it.)
2015-08-22 16:07:02 +03:00
const char *get_x_display(void *frontend)
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 16:29:52 +04:00
{
return gdk_get_display();
}
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 18:35:19 +03:00
#ifndef NOT_X_WINDOWS
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 15:57:37 +03:00
long get_windowid(void *frontend)
{
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 22:36:27 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
GTK3 port: respell GDK_WINDOW_XWINDOW / GDK_DRAWABLE_XID. GDK3 now spells both of those as GDK_WINDOW_XID. (Of course 'drawable' is no longer a relevant concept in GDK3, since pixmaps are no longer supported and so all drawables are just windows.) We keep backwards compatibility, of course.
2015-08-16 16:16:23 +03:00
return (long)GDK_WINDOW_XID(gtk_widget_get_window(inst->area));
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 15:57:37 +03: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 18:35:19 +03:00
#endif
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 15:57:37 +03:00
RJK's `pterm --help' patch. I _must_ find a better alternative to this init sequence - it surely can't be right that `pterm --help' with no DISPLAY complains at the lack of DISPLAY rather than giving a help message! [originally from svn r2164]
2002-10-30 21:22:37 +03:00
static void help(FILE *fp) {
if(fprintf(fp,
"pterm option summary:\n"
"\n"
" --display DISPLAY Specify X display to use (note '--')\n"
" -name PREFIX Prefix when looking up resources (default: pterm)\n"
" -fn FONT Normal text font\n"
" -fb FONT Bold text font\n"
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 17:49:12 +04:00
" -geometry GEOMETRY Position and size of window (size in characters)\n"
RJK's `pterm --help' patch. I _must_ find a better alternative to this init sequence - it surely can't be right that `pterm --help' with no DISPLAY complains at the lack of DISPLAY rather than giving a help message! [originally from svn r2164]
2002-10-30 21:22:37 +03:00
" -sl LINES Number of lines of scrollback\n"
" -fg COLOUR, -bg COLOUR Foreground/background colour\n"
" -bfg COLOUR, -bbg COLOUR Foreground/background bold colour\n"
" -cfg COLOUR, -bfg COLOUR Foreground/background cursor colour\n"
" -T TITLE Window title\n"
" -ut, +ut Do(default) or do not update utmp\n"
" -ls, +ls Do(default) or do not make shell a login shell\n"
" -sb, +sb Do(default) or do not display a scrollbar\n"
" -log PATH Log all output to a file\n"
" -nethack Map numeric keypad to hjklyubn direction keys\n"
" -xrm RESOURCE-STRING Set an X resource\n"
" -e COMMAND [ARGS...] Execute command (consumes all remaining args)\n"
) < 0 || fflush(fp) < 0) {
perror("output error");
exit(1);
}
}
Make --help and --version work consistently across all tools. Well, at least across all command-line tools on both Windows and Unix, and the GTK apps on Unix too. The Windows GUI apps fundamentally can't write to standard output and it doesn't seem sensible to use message boxes for these purposes :-) [originally from svn r9673]
2012-09-19 21:08:15 +04:00
static void version(FILE *fp) {
if(fprintf(fp, "%s: %s\n", appname, ver) < 0 || fflush(fp) < 0) {
perror("output error");
exit(1);
}
}
Since r7265, a user could not launch a PuTTY session to a specific host by simply specifying a hostname on the command line -- this would bring up the config dialog. Use a slightly more sophisticated notion of whether the user meant to launch a session. [originally from svn r7321] [r7265 == 5d76e00dac9220e8798e4d0f17a4069a58ae1667]
2007-02-25 03:50:24 +03:00
int do_cmdline(int argc, char **argv, int do_everything, int *allow_launch,
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 22:52:21 +04:00
struct gui_data *inst, Conf *conf)
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 20:45:23 +04:00
{
Added two simple command-line arguments: -fn (so I can have my Font Of Choice back :-) and -e to run a command other than $SHELL. [originally from svn r2037]
2002-10-13 16:54:17 +04:00
int err = 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 21:37:15 +04:00
char *val;
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 20:45:23 +04:00
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
/*
Fix command-line error handling in pterm. (Hint: wrapping a multi- statement macro in `do ... while (0)' and putting a `continue' within it don't go well together. Oops.) [originally from svn r2192]
2002-11-05 16:20:42 +03:00
* Macros to make argument handling easier. Note that because
* they need to call `continue', they cannot be contained in
* the usual do {...} while (0) wrapper to make them
* syntactically single statements; hence it is not legal to
* use one of these macros as an unbraced statement between
* `if' and `else'.
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
*/
Fix command-line error handling in pterm. (Hint: wrapping a multi- statement macro in `do ... while (0)' and putting a `continue' within it don't go well together. Oops.) [originally from svn r2192]
2002-11-05 16:20:42 +03:00
#define EXPECTS_ARG { \
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
if (--argc <= 0) { \
err = 1; \
All the stderr messages in this file now use appname rather than guessing wrongly. [originally from svn r3089]
2003-04-10 15:57:11 +04:00
fprintf(stderr, "%s: %s expects an argument\n", appname, p); \
Fix command-line error handling in pterm. (Hint: wrapping a multi- statement macro in `do ... while (0)' and putting a `continue' within it don't go well together. Oops.) [originally from svn r2192]
2002-11-05 16:20:42 +03:00
continue; \
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
} else \
val = *++argv; \
Fix command-line error handling in pterm. (Hint: wrapping a multi- statement macro in `do ... while (0)' and putting a `continue' within it don't go well together. Oops.) [originally from svn r2192]
2002-11-05 16:20:42 +03:00
}
#define SECOND_PASS_ONLY { if (!do_everything) continue; }
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
Added two simple command-line arguments: -fn (so I can have my Font Of Choice back :-) and -e to run a command other than $SHELL. [originally from svn r2037]
2002-10-13 16:54:17 +04:00
while (--argc > 0) {
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 13:15:42 +03:00
const char *p = *++argv;
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
int ret;
Reinstate `-T title', in pterm only. [originally from svn r3165]
2003-05-06 23:55:00 +04:00
/*
* Shameless cheating. Debian requires all X terminal
* emulators to support `-T title'; but
* cmdline_process_param will eat -T (it means no-pty) and
* complain that pterm doesn't support it. So, in pterm
* only, we convert -T into -title.
*/
if ((cmdline_tooltype & TOOLTYPE_NONNETWORK) &&
!strcmp(p, "-T"))
p = "-title";
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
ret = cmdline_process_param(p, (argc > 1 ? argv[1] : NULL),
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 22:52:21 +04:00
do_everything ? 1 : -1, conf);
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
if (ret == -2) {
cmdline_error("option \"%s\" requires an argument", p);
} else if (ret == 2) {
--argc, ++argv; /* skip next argument */
continue;
} else if (ret == 1) {
continue;
}
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
if (!strcmp(p, "-fn") || !strcmp(p, "-font")) {
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 21:38:59 +04:00
FontSpec *fs;
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 21:38:59 +04:00
fs = fontspec_new(val);
conf_set_fontspec(conf, CONF_font, fs);
fontspec_free(fs);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
} else if (!strcmp(p, "-fb")) {
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 21:38:59 +04:00
FontSpec *fs;
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 21:38:59 +04:00
fs = fontspec_new(val);
Fix copy-and-paste error in command-line font selection in r9314. [originally from svn r9315] [r9314 == 9c75fe9a3fa5e6b709f1c210795d1140ca1be2e8]
2011-10-01 22:00:49 +04:00
conf_set_fontspec(conf, CONF_boldfont, fs);
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 21:38:59 +04:00
fontspec_free(fs);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04: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-02 00:53:22 +03:00
} else if (!strcmp(p, "-fw")) {
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 21:38:59 +04:00
FontSpec *fs;
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-02 00:53:22 +03:00
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 21:38:59 +04:00
fs = fontspec_new(val);
Fix copy-and-paste error in command-line font selection in r9314. [originally from svn r9315] [r9314 == 9c75fe9a3fa5e6b709f1c210795d1140ca1be2e8]
2011-10-01 22:00:49 +04:00
conf_set_fontspec(conf, CONF_widefont, fs);
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 21:38:59 +04:00
fontspec_free(fs);
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-02 00:53:22 +03:00
} else if (!strcmp(p, "-fwb")) {
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 21:38:59 +04:00
FontSpec *fs;
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-02 00:53:22 +03:00
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 21:38:59 +04:00
fs = fontspec_new(val);
Fix copy-and-paste error in command-line font selection in r9314. [originally from svn r9315] [r9314 == 9c75fe9a3fa5e6b709f1c210795d1140ca1be2e8]
2011-10-01 22:00:49 +04:00
conf_set_fontspec(conf, CONF_wideboldfont, fs);
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 21:38:59 +04:00
fontspec_free(fs);
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-02 00:53:22 +03: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 15:20:34 +03:00
} else if (!strcmp(p, "-cs")) {
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_str(conf, CONF_line_codepage, val);
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 15:20:34 +03:00
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-geometry")) {
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 20:22:05 +03:00
#if GTK_CHECK_VERSION(2,0,0)
inst->geometry = val;
#else
/* On GTK 1, we have to do this using raw Xlib */
{
int flags, x, y;
unsigned int w, h;
flags = XParseGeometry(val, &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;
inst->gotpos = TRUE;
inst->gravity = ((flags & XNegative ? 1 : 0) |
(flags & YNegative ? 2 : 0));
}
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 17:49:12 +04: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 18:35:19 +03:00
#endif
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-sl")) {
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_savelines, atoi(val));
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-fg") || !strcmp(p, "-bg") ||
!strcmp(p, "-bfg") || !strcmp(p, "-bbg") ||
Ahem. Global replace of `cfg' with `inst->cfg' is all very well, but let's try to make sure it doesn't happen inside any strings! The -cfg option for cursor foreground colour nearly had a nasty accident there. [originally from svn r2569]
2003-01-12 18:36:05 +03:00
!strcmp(p, "-cfg") || !strcmp(p, "-cbg")) {
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
EXPECTS_ARG;
SECOND_PASS_ONLY;
Switch to gdk_rgba_parse() for GDK 3. I'm using a slightly more up-to-date GTK version for testing on MacOS, and it's marked a few more functions as deprecated, among which is gdk_color_parse(). So now parsing -fg and -bg options has to be done by two different calls and an ugly #ifdef, depending on GTK version.
2015-08-31 15:37:30 +03:00
{
#if GTK_CHECK_VERSION(3,0,0)
GdkRGBA rgba;
int success = gdk_rgba_parse(&rgba, val);
#else
GdkColor col;
int success = gdk_color_parse(val, &col);
#endif
if (!success) {
err = 1;
fprintf(stderr, "%s: unable to parse colour \"%s\"\n",
appname, val);
} else {
#if GTK_CHECK_VERSION(3,0,0)
int r = rgba.red * 255;
int g = rgba.green * 255;
int b = rgba.blue * 255;
#else
int r = col.red / 256;
int g = col.green / 256;
int b = col.blue / 256;
#endif
int index;
index = (!strcmp(p, "-fg") ? 0 :
!strcmp(p, "-bg") ? 2 :
!strcmp(p, "-bfg") ? 1 :
!strcmp(p, "-bbg") ? 3 :
!strcmp(p, "-cfg") ? 4 :
!strcmp(p, "-cbg") ? 5 : -1);
assert(index != -1);
conf_set_int_int(conf, CONF_colours, index*3+0, r);
conf_set_int_int(conf, CONF_colours, index*3+1, g);
conf_set_int_int(conf, CONF_colours, index*3+2, b);
}
}
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
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 22:52:50 +03:00
} else if (use_pty_argv && !strcmp(p, "-e")) {
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
/* This option swallows all further arguments. */
if (!do_everything)
break;
Added two simple command-line arguments: -fn (so I can have my Font Of Choice back :-) and -e to run a command other than $SHELL. [originally from svn r2037]
2002-10-13 16:54:17 +04:00
if (--argc > 0) {
int i;
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
pty_argv = snewn(argc+1, char *);
Added two simple command-line arguments: -fn (so I can have my Font Of Choice back :-) and -e to run a command other than $SHELL. [originally from svn r2037]
2002-10-13 16:54:17 +04:00
++argv;
for (i = 0; i < argc; i++)
pty_argv[i] = argv[i];
pty_argv[argc] = NULL;
break; /* finished command-line processing */
} else
All the stderr messages in this file now use appname rather than guessing wrongly. [originally from svn r3089]
2003-04-10 15:57:11 +04:00
err = 1, fprintf(stderr, "%s: -e expects an argument\n",
appname);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
Rename pterm's -T option to -title, to avoid clashing with PuTTY's -T (don't allocate a pty) option. [originally from svn r3079]
2003-04-08 18:02:34 +04:00
} else if (!strcmp(p, "-title")) {
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_str(conf, CONF_wintitle, val);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
} else if (!strcmp(p, "-log")) {
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 15:01:57 +04:00
Filename *fn;
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
EXPECTS_ARG;
SECOND_PASS_ONLY;
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 15:01:57 +04:00
fn = filename_from_str(val);
conf_set_filename(conf, CONF_logfilename, fn);
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 22:52:21 +04:00
conf_set_int(conf, CONF_logtype, LGTYP_DEBUG);
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 15:01:57 +04:00
filename_free(fn);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-ut-") || !strcmp(p, "+ut")) {
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_stamp_utmp, 0);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-ut")) {
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_stamp_utmp, 1);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-ls-") || !strcmp(p, "+ls")) {
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_login_shell, 0);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-ls")) {
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_login_shell, 1);
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
} else if (!strcmp(p, "-nethack")) {
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_nethack_keypad, 1);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-sb-") || !strcmp(p, "+sb")) {
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_scrollbar, 0);
A few more command-line options. [originally from svn r2086]
2002-10-16 20:00:38 +04:00
} else if (!strcmp(p, "-sb")) {
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
SECOND_PASS_ONLY;
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 22:52:21 +04:00
conf_set_int(conf, CONF_scrollbar, 1);
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
} else if (!strcmp(p, "-name")) {
EXPECTS_ARG;
app_name = val;
Add the -xrm command-line option, to allow specification of an arbitrary X resource which doesn't have a dedicated command-line option. [originally from svn r2089]
2002-10-17 02:54:58 +04:00
} else if (!strcmp(p, "-xrm")) {
EXPECTS_ARG;
provide_xrm_string(val);
RJK's `pterm --help' patch. I _must_ find a better alternative to this init sequence - it surely can't be right that `pterm --help' with no DISPLAY complains at the lack of DISPLAY rather than giving a help message! [originally from svn r2164]
2002-10-30 21:22:37 +03:00
} else if(!strcmp(p, "-help") || !strcmp(p, "--help")) {
help(stdout);
exit(0);
Try to make our PGP signing more useful: * All the PuTTY tools for Windows and Unix now contain the fingerprints of the Master Keys. The method for accessing them is crude but universal: a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes "--pgpfp" just to be awkward.) * Move the key policy discussion from putty-website/keys.html to putty/doc/pgpkeys.but, and autogenerate the former from the latter. Also tweak the text somewhat and include the fingerprints of the Master Keys themselves. (I've merged the existing autogeneration scripts into a single new one; I've left the old scripts and keys.html around until such time as the webmonster reviews the changes and plumbs in the new script; he should remove the old files then.) [originally from svn r5524] [this svn revision also touched putty-website]
2005-03-19 05:26:58 +03:00
Make --help and --version work consistently across all tools. Well, at least across all command-line tools on both Windows and Unix, and the GTK apps on Unix too. The Windows GUI apps fundamentally can't write to standard output and it doesn't seem sensible to use message boxes for these purposes :-) [originally from svn r9673]
2012-09-19 21:08:15 +04:00
} else if(!strcmp(p, "-version") || !strcmp(p, "--version")) {
version(stdout);
exit(0);
Try to make our PGP signing more useful: * All the PuTTY tools for Windows and Unix now contain the fingerprints of the Master Keys. The method for accessing them is crude but universal: a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes "--pgpfp" just to be awkward.) * Move the key policy discussion from putty-website/keys.html to putty/doc/pgpkeys.but, and autogenerate the former from the latter. Also tweak the text somewhat and include the fingerprints of the Master Keys themselves. (I've merged the existing autogeneration scripts into a single new one; I've left the old scripts and keys.html around until such time as the webmonster reviews the changes and plumbs in the new script; he should remove the old files then.) [originally from svn r5524] [this svn revision also touched putty-website]
2005-03-19 05:26:58 +03:00
} else if (!strcmp(p, "-pgpfp")) {
pgp_fingerprints();
exit(1);
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
} else if(p[0] != '-' && (!do_everything ||
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 22:52:21 +04:00
process_nonoption_arg(p, conf,
Since r7265, a user could not launch a PuTTY session to a specific host by simply specifying a hostname on the command line -- this would bring up the config dialog. Use a slightly more sophisticated notion of whether the user meant to launch a session. [originally from svn r7321] [r7265 == 5d76e00dac9220e8798e4d0f17a4069a58ae1667]
2007-02-25 03:50:24 +03:00
allow_launch))) {
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
/* do nothing */
Reject unrecognised command-line options; thanks rjk. [originally from svn r2102]
2002-10-18 19:26:54 +04:00
} else {
err = 1;
All the stderr messages in this file now use appname rather than guessing wrongly. [originally from svn r3089]
2003-04-10 15:57:11 +04:00
fprintf(stderr, "%s: unrecognized option '%s'\n", appname, p);
Richard's patch to make the scrollbar configurably absent. (Still want a new option to configure it to be on the LHS though. And some lunatic is bound to ask for an xterm-style scrollbar too... :-) [originally from svn r2062]
2002-10-15 18:55:19 +04:00
}
Added two simple command-line arguments: -fn (so I can have my Font Of Choice back :-) and -e to run a command other than $SHELL. [originally from svn r2037]
2002-10-13 16:54:17 +04:00
}
Implement reading of X resources, and -name to change the name under which to look them up. [originally from svn r2084]
2002-10-16 18:32:06 +04:00
return err;
}
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
struct uxsel_id {
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#if GTK_CHECK_VERSION(2,0,0)
GIOChannel *chan;
guint watch_id;
#else
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
int id;
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#endif
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
};
uxsel_id *uxsel_input_add(int fd, int rwx) {
uxsel_id *id = snew(uxsel_id);
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#if GTK_CHECK_VERSION(2,0,0)
int flags = 0;
if (rwx & 1) flags |= G_IO_IN;
if (rwx & 2) flags |= G_IO_OUT;
if (rwx & 4) flags |= G_IO_PRI;
id->chan = g_io_channel_unix_new(fd);
g_io_channel_set_encoding(id->chan, NULL, NULL);
id->watch_id = g_io_add_watch(id->chan, flags, fd_input_func, NULL);
#else
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 21:30:14 +03:00
int flags = 0;
if (rwx & 1) flags |= GDK_INPUT_READ;
if (rwx & 2) flags |= GDK_INPUT_WRITE;
if (rwx & 4) flags |= GDK_INPUT_EXCEPTION;
Changed my mind about r7164. Instead of checking for zero flags inside one single uxsel front end, better to do it centrally and avoid passing zero flags on to the front end in the first place. I'm sure other similarly structured front ends could get confused by it too. [originally from svn r7171] [r7164 == 65f9735b95cc8bbf5e7e23f165c01fd3cddf9ec5]
2007-01-26 23:00:32 +03:00
assert(flags);
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
id->id = gdk_input_add(fd, flags, fd_input_func, NULL);
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#endif
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
return id;
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 21:30:14 +03:00
}
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
void uxsel_input_remove(uxsel_id *id) {
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#if GTK_CHECK_VERSION(2,0,0)
g_source_remove(id->watch_id);
g_io_channel_unref(id->chan);
#else
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
gdk_input_remove(id->id);
Reimplement GTK uxsel_input_add using GIOChannel. This is the new recommended approach since gdk_input_{add,remove} were deprecated (and, honestly, seems a lot more sensible - why on earth would those functions have lived in *GDK* of all places?). The old implementation is preserved under ifdef for GTK1. This was the last of the GDK deprecated functions to go! So GTK PuTTY now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all the other precautionary flags (though if you do that, you disable GDK rendering, which greatly slows down server-side font handling). This completes the GTK2-compatible preparation phase of the GTK 3 migration guide.
2015-08-16 15:07:26 +03:00
#endif
Change uxsel_input_add's return type from int to pointer. In case a front end needs to store more than an integer id to be returned to uxsel_input_remove, we now return a pointer to a frontend-defined structure.
2015-08-16 14:50:46 +03:00
sfree(id);
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 21:30:14 +03:00
}
pterm: set IUTF8 on pty devices depending on charset. In a UTF-8 pterm, it makes sense to set the IUTF8 flag (on systems that have one) on the pty device, so that line editing will take account of UTF-8 multibyte characters.
2015-09-01 20:35:38 +03:00
int frontend_is_utf8(void *frontend)
{
struct gui_data *inst = (struct gui_data *)frontend;
return inst->ucsdata.line_codepage == CS_UTF8;
}
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-14 01:59:10 +04:00
char *setup_fonts_ucs(struct gui_data *inst)
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
int shadowbold = conf_get_int(inst->conf, CONF_shadowbold);
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-14 01:59:10 +04:00
unifont *fonts[4];
int i;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
fs = conf_get_fontspec(inst->conf, CONF_font);
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-14 01:59:10 +04:00
fonts[0] = multifont_create(inst->area, fs->name, FALSE, FALSE,
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 22:00:50 +04: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 14:15:00 +04: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 22:52:21 +04:00
fs = conf_get_fontspec(inst->conf, CONF_boldfont);
if (shadowbold || !fs->name[0]) {
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-14 01:59:10 +04: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 14:15:00 +04:00
} else {
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-14 01:59:10 +04:00
fonts[1] = multifont_create(inst->area, fs->name, FALSE, TRUE,
shadowboldoffset, shadowbold);
if (!fonts[1]) {
if (fonts[0])
unifont_destroy(fonts[0]);
return dupprintf("unable to load bold font \"%s\"", fs->name);
Richard B's patch to enable users to explicitly request shadow bold by disabling bold-font-name guessing (if their bold fonts are ugly). I've turned the UI inside out, but the meat is pretty much the same. [originally from svn r3410]
2003-08-21 22:39:17 +04: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 14:15:00 +04: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 22:52:21 +04:00
fs = conf_get_fontspec(inst->conf, CONF_widefont);
if (fs->name[0]) {
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-14 01:59:10 +04:00
fonts[2] = multifont_create(inst->area, fs->name, TRUE, FALSE,
shadowboldoffset, shadowbold);
if (!fonts[2]) {
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 18:05:44 +04:00
return dupprintf("unable to load wide font \"%s\"", fs->name);
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 14:40:23 +03: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 14:15:00 +04:00
} else {
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-14 01:59:10 +04: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 14:15:00 +04: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 22:52:21 +04:00
fs = conf_get_fontspec(inst->conf, CONF_wideboldfont);
if (shadowbold || !fs->name[0]) {
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-14 01:59:10 +04: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 14:15:00 +04:00
} else {
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-14 01:59:10 +04:00
fonts[3] = multifont_create(inst->area, fs->name, TRUE, TRUE,
shadowboldoffset, shadowbold);
if (!fonts[3]) {
for (i = 0; i < 3; 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 18:05:44 +04:00
return dupprintf("unable to load wide bold font \"%s\"", fs->name);
Richard B's patch to enable users to explicitly request shadow bold by disabling bold-font-name guessing (if their bold fonts are ugly). I've turned the UI inside out, but the meat is pretty much the same. [originally from svn r3410]
2003-08-21 22:39:17 +04: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 14:15:00 +04:00
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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-14 01:59:10 +04: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];
}
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 14:40:23 +03:00
inst->font_width = inst->fonts[0]->width;
inst->font_height = inst->fonts[0]->height;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
inst->direct_to_font = init_ucs(&inst->ucsdata,
conf_get_str(inst->conf, CONF_line_codepage),
conf_get_int(inst->conf, CONF_utf8_override),
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 14:40:23 +03:00
inst->fonts[0]->public_charset,
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 22:52:21 +04:00
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-14 01:59:10 +04: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 23:05:56 +03: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-14 01:59:10 +04:00
return NULL;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
}
void set_geom_hints(struct gui_data *inst)
{
GdkGeometry geom;
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 22:52:21 +04:00
geom.min_width = inst->font_width + 2*inst->window_border;
geom.min_height = inst->font_height + 2*inst->window_border;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
geom.max_width = geom.max_height = -1;
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 22:52:21 +04:00
geom.base_width = 2*inst->window_border;
geom.base_height = 2*inst->window_border;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
geom.width_inc = inst->font_width;
geom.height_inc = inst->font_height;
geom.min_aspect = geom.max_aspect = 0;
gtk_window_set_geometry_hints(GTK_WINDOW(inst->window), inst->area, &geom,
GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE |
GDK_HINT_RESIZE_INC);
}
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 20:05:00 +04:00
void clear_scrollback_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
term_clrsb(inst->term);
}
void reset_terminal_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
Fix `restart-reset-terminal': terminal now restored to a sensible state when reusing a window to restart a session. [originally from svn r6577] [this svn revision also touched putty-wishlist]
2006-02-19 17:59:48 +03: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 17:04:18 +04:00
if (inst->ldisc)
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 19:12:47 +03: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 20:05:00 +04:00
}
`Copy All' context-menu item, for what it's worth. [originally from svn r3097]
2003-04-11 21:59:36 +04:00
void copy_all_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
term_copyall(inst->term);
}
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 20:05:00 +04:00
void special_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)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 19:29:02 +03:00
int code = GPOINTER_TO_INT(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 20:05:00 +04: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 17:04:18 +04:00
if (inst->back)
inst->back->special(inst->backhandle, code);
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 20:05:00 +04:00
}
void about_menuitem(GtkMenuItem *item, gpointer 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 12:53:43 +04:00
struct gui_data *inst = (struct gui_data *)data;
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 20:05:00 +04: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 22:46:45 +04:00
void event_log_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
showeventlog(inst->eventlogstuff, inst->window);
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
void change_settings_menuitem(GtkMenuItem *item, gpointer data)
{
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 22:52:21 +04:00
/* This maps colour indices in inst->conf to those used in inst->cols. */
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
static const int ww[] = {
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
256, 257, 258, 259, 260, 261,
0, 8, 1, 9, 2, 10, 3, 11,
4, 12, 5, 13, 6, 14, 7, 15
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
};
struct gui_data *inst = (struct gui_data *)data;
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04:00
char *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 22:52:21 +04:00
Conf *oldconf, *newconf;
int i, j, need_size;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
assert(lenof(ww) == NCFGCOLOURS);
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 13:07:27 +03:00
if (inst->reconfiguring)
return;
else
inst->reconfiguring = TRUE;
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04:00
title = dupcat(appname, " Reconfiguration", NULL);
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 22:52:21 +04:00
oldconf = inst->conf;
newconf = conf_copy(inst->conf);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
if (do_config_box(title, newconf, 1,
Loose end from r5031: the Kex panel should only be displayed in mid-session if we are not using SSHv1. I've done this by introducing a generic `cfg_info' function which every back end can use to communicate an int's worth of data to setup_config_box; in SSH that's the protocol version in use, and in everything else it's currently zero. [originally from svn r5040] [r5031 == d77102a8d535a7000d6d909529a61a1564f6d678]
2004-12-29 15:32:25 +03:00
inst->back?inst->back->cfg_info(inst->backhandle):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 22:52:21 +04:00
inst->conf = newconf;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
log_reconfig(inst->logctx, inst->conf);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 21:24:20 +04: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 19:12:47 +03: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 21:24:20 +04:00
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
term_reconfig(inst->term, inst->conf);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
/* Pass new config data to the back end */
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 17:04:18 +04:00
if (inst->back)
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 22:52:21 +04:00
inst->back->reconfig(inst->backhandle, inst->conf);
cache_conf_values(inst);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
* Just setting inst->conf is sufficient to cause colour
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
* setting changes to appear on the next ESC]R palette
* reset. But we should also check whether any colour
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 22:52:21 +04:00
* settings have been changed, and revert the ones that have
* to the new default, on the assumption that the user is
* most likely to want an immediate update.
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
*/
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 18:13:34 +03:00
for (i = 0; i < NCFGCOLOURS; i++) {
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 22:52:21 +04:00
for (j = 0; j < 3; j++)
if (conf_get_int_int(oldconf, CONF_colours, i*3+j) !=
conf_get_int_int(newconf, CONF_colours, i*3+j))
break;
if (j < 3) {
real_palette_set(inst, ww[i],
conf_get_int_int(newconf,CONF_colours,i*3+0),
conf_get_int_int(newconf,CONF_colours,i*3+1),
conf_get_int_int(newconf,CONF_colours,i*3+2));
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 22:14:14 +04:00
/*
* If the default background has changed, we must
* repaint the space in between the window border
* and the text area.
*/
Fix an always-false if statement which was causing the window border not to be redrawn when the user reconfigured the background colour. [originally from svn r9917]
2013-07-14 14:45:48 +04:00
if (ww[i] == 258) {
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 22:14:14 +04:00
set_window_background(inst);
draw_backing_rect(inst);
}
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
}
/*
* If the scrollbar needs to be shown, hidden, or moved
* from one end to the other of the window, do so now.
*/
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 22:52:21 +04:00
if (conf_get_int(oldconf, CONF_scrollbar) !=
conf_get_int(newconf, CONF_scrollbar)) {
if (conf_get_int(newconf, CONF_scrollbar))
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
gtk_widget_show(inst->sbar);
else
gtk_widget_hide(inst->sbar);
}
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 22:52:21 +04:00
if (conf_get_int(oldconf, CONF_scrollbar_on_left) !=
conf_get_int(newconf, CONF_scrollbar_on_left)) {
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
gtk_box_reorder_child(inst->hbox, inst->sbar,
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 22:52:21 +04:00
conf_get_int(newconf, CONF_scrollbar_on_left)
? 0 : 1);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
}
/*
* Change the window title, if required.
*/
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 22:52:21 +04:00
if (strcmp(conf_get_str(oldconf, CONF_wintitle),
conf_get_str(newconf, CONF_wintitle)))
Fix bug with setting window title on Unix that came in with r9214. [originally from svn r9268] [r9214 == a1f3b7a358adaa7c2a98359cd0373aa823eeb14b]
2011-08-19 18:55:24 +04:00
set_title(inst, conf_get_str(newconf, CONF_wintitle));
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 17:55:47 +04:00
set_window_titles(inst);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
/*
* Redo the whole tangled fonts and Unicode mess if
* necessary.
*/
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-14 01:59:10 +04:00
need_size = FALSE;
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 22:52:21 +04:00
if (strcmp(conf_get_fontspec(oldconf, CONF_font)->name,
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)) ||
Bug fix from Robert de Bath: if the utf8_override setting is changed in mid-session, it affects translation and hence display, so it should be listed among the settings that require a redraw. [originally from svn r9466]
2012-04-22 18:22:08 +04:00
conf_get_int(oldconf, CONF_utf8_override) !=
conf_get_int(newconf, CONF_utf8_override) ||
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 22:52:21 +04:00
conf_get_int(oldconf, CONF_vtmode) !=
conf_get_int(newconf, CONF_vtmode) ||
conf_get_int(oldconf, CONF_shadowbold) !=
conf_get_int(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-14 01:59:10 +04:00
char *errmsg = setup_fonts_ucs(inst);
if (errmsg) {
char *msgboxtext =
dupprintf("Could not change fonts in terminal window: %s\n",
errmsg);
messagebox(inst->window, "Font setup error", msgboxtext,
string_width("Could not change fonts in terminal window:"),
"OK", 'o', +1, 1,
NULL);
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04: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-14 01:59:10 +04:00
sfree(errmsg);
} else {
need_size = TRUE;
}
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:52:21 +04:00
if (conf_get_int(oldconf, CONF_width) !=
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 22:00:50 +04:00
set_geom_hints(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 22:52:21 +04:00
request_resize(inst, 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 14:44:14 +04:00
} else {
/*
* 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.
*/
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 22:52:21 +04:00
if (conf_get_int(oldconf, CONF_savelines) !=
conf_get_int(newconf, CONF_savelines))
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 14:44:14 +04:00
term_size(inst->term, inst->term->rows, inst->term->cols,
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 22:52:21 +04:00
conf_get_int(newconf, CONF_savelines));
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 14:44:14 +04:00
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 22:14:14 +04: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 22:52:21 +04:00
conf_free(oldconf);
} else {
conf_free(newconf);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
}
sfree(title);
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 13:07:27 +03:00
inst->reconfiguring = FALSE;
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 21:37:15 +04:00
void fork_and_exec_self(struct gui_data *inst, int fd_to_close, ...)
{
/*
* Re-execing ourself is not an exact science under Unix. I do
* the best I can by using /proc/self/exe if available and by
* assuming argv[0] can be found on $PATH if not.
*
* Note that we also have to reconstruct the elements of the
* original argv which gtk swallowed, since the user wants the
* new session to appear on the same X display as the old one.
*/
char **args;
va_list ap;
int i, n;
int pid;
/*
* Collect the arguments with which to re-exec ourself.
*/
va_start(ap, fd_to_close);
n = 2; /* progname and terminating NULL */
n += inst->ngtkargs;
while (va_arg(ap, char *) != NULL)
n++;
va_end(ap);
args = snewn(n, char *);
args[0] = inst->progname;
args[n-1] = NULL;
for (i = 0; i < inst->ngtkargs; i++)
args[i+1] = inst->gtkargvstart[i];
i++;
va_start(ap, fd_to_close);
while ((args[i++] = va_arg(ap, char *)) != NULL);
va_end(ap);
assert(i == n);
/*
* Do the double fork.
*/
pid = fork();
if (pid < 0) {
perror("fork");
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04:00
sfree(args);
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 21:37:15 +04:00
return;
}
if (pid == 0) {
int pid2 = fork();
if (pid2 < 0) {
perror("fork");
_exit(1);
} else if (pid2 > 0) {
/*
* First child has successfully forked second child. My
* Work Here Is Done. Note the use of _exit rather than
* exit: the latter appears to cause destroy messages
* to be sent to the X server. I suspect gtk uses
* atexit.
*/
_exit(0);
}
/*
* If we reach here, we are the second child, so we now
* actually perform the exec.
*/
if (fd_to_close >= 0)
close(fd_to_close);
execv("/proc/self/exe", args);
execvp(inst->progname, args);
perror("exec");
_exit(127);
} else {
int status;
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04:00
sfree(args);
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 21:37:15 +04:00
waitpid(pid, &status, 0);
}
}
void dup_session_menuitem(GtkMenuItem *item, gpointer gdata)
{
struct gui_data *inst = (struct gui_data *)gdata;
/*
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 22:52:21 +04:00
* For this feature we must marshal conf and (possibly) pty_argv
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 21:37:15 +04:00
* into a byte stream, create a pipe, and send this byte stream
* to the child through the pipe.
*/
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 22:52:21 +04:00
int i, ret, sersize, size;
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 21:37:15 +04:00
char *data;
char option[80];
int pipefd[2];
if (pipe(pipefd) < 0) {
perror("pipe");
return;
}
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 22:52:21 +04:00
size = sersize = conf_serialised_size(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 21:37:15 +04:00
if (use_pty_argv && pty_argv) {
for (i = 0; pty_argv[i]; i++)
size += strlen(pty_argv[i]) + 1;
}
data = snewn(size, char);
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 22:52:21 +04:00
conf_serialise(inst->conf, 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 21:37:15 +04:00
if (use_pty_argv && pty_argv) {
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 22:52:21 +04:00
int p = sersize;
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 21:37:15 +04:00
for (i = 0; pty_argv[i]; i++) {
strcpy(data + p, pty_argv[i]);
p += strlen(pty_argv[i]) + 1;
}
assert(p == size);
}
sprintf(option, "---[%d,%d]", pipefd[0], size);
Centralise calls to fcntl into functions that carefully check the error returns. [originally from svn r9940]
2013-07-19 22:10:02 +04:00
noncloexec(pipefd[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 21:37:15 +04:00
fork_and_exec_self(inst, pipefd[1], option, NULL);
close(pipefd[0]);
Unix makefile now uses -O2, which massively cuts down key exchange time. This gives rise to a whole bunch of spare warnings, one or two of which might have been actual bugs; now all resolved. [originally from svn r3134]
2003-04-23 17:48:09 +04:00
i = ret = 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 21:37:15 +04:00
while (i < size && (ret = write(pipefd[1], data + i, size - i)) > 0)
i += ret;
if (ret < 0)
perror("write to pipe");
close(pipefd[1]);
sfree(data);
}
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 22:52:21 +04:00
int read_dupsession_data(struct gui_data *inst, Conf *conf, char *arg)
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 21:37:15 +04: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 22:52:21 +04:00
int fd, i, ret, size, size_used;
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 21:37:15 +04:00
char *data;
if (sscanf(arg, "---[%d,%d]", &fd, &size) != 2) {
fprintf(stderr, "%s: malformed magic argument `%s'\n", appname, arg);
exit(1);
}
data = snewn(size, char);
Unix makefile now uses -O2, which massively cuts down key exchange time. This gives rise to a whole bunch of spare warnings, one or two of which might have been actual bugs; now all resolved. [originally from svn r3134]
2003-04-23 17:48:09 +04:00
i = ret = 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 21:37:15 +04:00
while (i < size && (ret = read(fd, data + i, size - i)) > 0)
i += ret;
if (ret < 0) {
perror("read from pipe");
exit(1);
} else if (i < size) {
fprintf(stderr, "%s: unexpected EOF in Duplicate Session data\n",
appname);
exit(1);
}
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 22:52:21 +04:00
size_used = conf_deserialise(conf, data, size);
if (use_pty_argv && size > size_used) {
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 21:37:15 +04:00
int n = 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 22:52:21 +04:00
i = size_used;
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 21:37:15 +04:00
while (i < size) {
while (i < size && data[i]) i++;
if (i >= size) {
fprintf(stderr, "%s: malformed Duplicate Session data\n",
appname);
exit(1);
}
i++;
n++;
}
pty_argv = snewn(n+1, char *);
pty_argv[n] = NULL;
n = 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 22:52:21 +04:00
i = size_used;
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 21:37:15 +04:00
while (i < size) {
char *p = data + i;
while (i < size && data[i]) i++;
assert(i < size);
i++;
pty_argv[n++] = dupstr(p);
}
}
Redo a mis-fix of a memory leak in r9919: I added sfree(data) immediately after conf_deserialise in the Duplicate Session receiver, whereas I should have put it after the subsequent loop that extracts the pty argv if any. [originally from svn r9943] [r9919 == ea301bdd9b892a5e70692f82f5c0b98bd585e775]
2013-07-20 17:15:10 +04:00
sfree(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 21:37:15 +04:00
return 0;
}
void new_session_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
fork_and_exec_self(inst, -1, 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 17:04:18 +04:00
void restart_session_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
if (!inst->back) {
logevent(inst, "----- Session restarted -----");
Fix `restart-reset-terminal': terminal now restored to a sensible state when reusing a window to restart a session. [originally from svn r6577] [this svn revision also touched putty-wishlist]
2006-02-19 17:59:48 +03:00
term_pwron(inst->term, 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 17:04:18 +04:00
start_backend(inst);
inst->exited = 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 21:37:15 +04:00
void saved_session_menuitem(GtkMenuItem *item, gpointer data)
{
struct gui_data *inst = (struct gui_data *)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 19:29:02 +03: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 21:37:15 +04:00
fork_and_exec_self(inst, -1, "-load", str, NULL);
}
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 19:29:02 +03: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 21:37:15 +04:00
sfree(str);
}
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 05:36:28 +04:00
static void update_savedsess_menu(GtkMenuItem *menuitem, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
struct sesslist sesslist;
int i;
gtk_container_foreach(GTK_CONTAINER(inst->sessionsmenu),
(GtkCallback)gtk_widget_destroy, NULL);
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-14 03:29:11 +04: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 05:36:28 +04:00
for (i = 1; i < sesslist.nsessions; i++) {
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 19:29:02 +03: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 05:36:28 +04: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-14 03:29:11 +04:00
if (sesslist.nsessions <= 1) {
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 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 05:36:28 +04:00
get_sesslist(&sesslist, FALSE); /* free up */
}
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 21:27:00 +03:00
void set_window_icon(GtkWidget *window, const char *const *const *icon,
int n_icon)
{
#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 11:41:10 +03: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 21:27:00 +03:00
#endif
if (!n_icon)
return;
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 11:41:10 +03: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 17:53:43 +03: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 11:41:10 +03:00
#endif
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 21:27:00 +03:00
#if GTK_CHECK_VERSION(2,0,0)
iconlist = NULL;
for (n = 0; n < n_icon; n++) {
iconlist =
g_list_append(iconlist,
gdk_pixbuf_new_from_xpm_data((const gchar **)
icon[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 11:41:10 +03: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 21:27:00 +03:00
#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 20:05:00 +04:00
void update_specials_menu(void *frontend)
{
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 22:36:27 +04:00
struct gui_data *inst = (struct gui_data *)frontend;
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 20:05:00 +04:00
const struct telnet_special *specials;
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 17:04:18 +04:00
if (inst->back)
specials = inst->back->get_specials(inst->backhandle);
else
specials = NULL;
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-18 01:22:22 +04: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 20:05:00 +04:00
gtk_container_foreach(GTK_CONTAINER(inst->specialsmenu),
(GtkCallback)gtk_widget_destroy, NULL);
if (specials) {
int i;
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-18 01:22:22 +04:00
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 TS_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 TS_EXITMENU:
nesting--;
if (nesting) {
menu = saved_menu; /* XXX lame stacking */
saved_menu = NULL;
}
break;
case TS_SEP:
menuitem = gtk_menu_item_new();
break;
default:
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 20:05:00 +04:00
menuitem = gtk_menu_item_new_with_label(specials[i].name);
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 19:29:02 +03:00
g_object_set_data(G_OBJECT(menuitem), "user-data",
GINT_TO_POINTER(specials[i].code));
g_signal_connect(G_OBJECT(menuitem), "activate",
G_CALLBACK(special_menuitem), inst);
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-18 01:22:22 +04:00
break;
}
if (menuitem) {
gtk_container_add(GTK_CONTAINER(menu), menuitem);
gtk_widget_show(menuitem);
}
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 20:05:00 +04:00
}
gtk_widget_show(inst->specialsitem1);
gtk_widget_show(inst->specialsitem2);
} else {
gtk_widget_hide(inst->specialsitem1);
gtk_widget_hide(inst->specialsitem2);
}
}
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 17:04:18 +04:00
static void start_backend(struct gui_data *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 18:32:06 +04: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 22:52:21 +04:00
extern Backend *select_backend(Conf *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 17:04:18 +04:00
char *realhost;
const char *error;
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 22:52:21 +04:00
char *s;
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 17:04:18 +04: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 22:52:21 +04:00
inst->back = 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 17:04:18 +04:00
error = inst->back->init((void *)inst, &inst->backhandle,
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 22:52:21 +04:00
inst->conf,
conf_get_str(inst->conf, CONF_host),
conf_get_int(inst->conf, CONF_port),
&realhost,
conf_get_int(inst->conf, CONF_tcp_nodelay),
conf_get_int(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 17:04:18 +04:00
if (error) {
char *msg = dupprintf("Unable to open connection to %s:\n%s",
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 22:52:21 +04:00
conf_get_str(inst->conf, CONF_host), error);
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 17:04:18 +04:00
inst->exited = TRUE;
fatal_message_box(inst->window, msg);
sfree(msg);
exit(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 22:52:21 +04:00
s = conf_get_str(inst->conf, CONF_wintitle);
if (s[0]) {
set_title_and_icon(inst, s, s);
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 17:04:18 +04:00
} else {
char *title = make_default_wintitle(realhost);
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 22:52:21 +04:00
set_title_and_icon(inst, title, title);
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 17:04:18 +04:00
sfree(title);
}
Fix minor memory leak. [originally from svn r6611]
2006-03-15 01:01:27 +03:00
sfree(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 17:04:18 +04:00
inst->back->provide_logctx(inst->backhandle, inst->logctx);
term_provide_resize_fn(inst->term, inst->back->size, inst->backhandle);
inst->ldisc =
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 22:52:21 +04:00
ldisc_create(inst->conf, inst->term, inst->back, inst->backhandle,
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 17:04:18 +04:00
inst);
In Unix PuTTY, grey out "Restart Session" when it doesn't apply (as the Windows version does), rather than hiding it completely. [originally from svn r8650]
2009-09-14 03:41:55 +04: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 17:04:18 +04:00
}
int pt_main(int argc, char **argv)
{
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 22:52:21 +04:00
extern int cfgbox(Conf *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 16:58:13 +04:00
struct gui_data *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 18:32:06 +04: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 11:26:23 +04:00
setlocale(LC_CTYPE, "");
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 21:37:15 +04:00
/*
* Create an instance structure and initialise to zeroes
*/
inst = snew(struct gui_data);
memset(inst, 0, sizeof(*inst));
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 20:05:58 +03:00
inst->busy_status = BUSY_NOT;
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 22:52:21 +04:00
inst->conf = conf_new();
inst->wintitle = inst->icontitle = NULL;
Make GTK idle and quit function setup idempotent. I found last week that when a local proxy process terminated unexpectedly, Unix PuTTY went into a tight loop calling quit functions, because if idle_toplevel_callback_func is called from inside a subsidiary gtk_main then it will schedule a quit function and _not_ disable itself, so that that quit function keeps being rescheduled on subsequent calls. To fix, I've tried to make the whole handling of idle and quit functions more sensibly robust: we keep our own boolean flag indicating whether each of our functions has already been scheduled with GTK, and if so, we don't schedule the same one again. Also, when idle_toplevel_callback_func schedules a quit function, it should unschedule itself since it's now done everything it can until a gtk_main instance quits. [originally from svn r10100]
2013-11-30 22:04:57 +04:00
inst->quit_fn_scheduled = FALSE;
inst->idle_fn_scheduled = 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 23:05:56 +03:00
inst->drawtype = DRAWTYPE_DEFAULT;
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 21:37:15 +04:00
RJK's general signal-handling robustness patch. Should fix the weird spin behaviour occasionally seen after pterm's child process dies. [originally from svn r2181]
2002-11-02 17:35:57 +03:00
/* defer any child exit handling until we're ready to deal with
* it */
block_signal(SIGCHLD, 1);
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 21:37:15 +04:00
inst->progname = argv[0];
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 15:58:59 +04: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 21:37:15 +04:00
* Copy the original argv before letting gtk_init fiddle with
* it. It will be required later.
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 15:58:59 +04: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 21:37:15 +04:00
{
int i, oldargc;
inst->gtkargvstart = snewn(argc-1, char *);
for (i = 1; i < argc; i++)
inst->gtkargvstart[i-1] = dupstr(argv[i]);
oldargc = argc;
gtk_init(&argc, &argv);
inst->ngtkargs = oldargc - argc;
}
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 15:58:59 +04: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 21:37:15 +04:00
if (argc > 1 && !strncmp(argv[1], "---", 3)) {
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 22:52:21 +04:00
read_dupsession_data(inst, inst->conf, argv[1]);
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 21:37:15 +04:00
/* Splatter this argument so it doesn't clutter a ps listing */
Introduce a new utility function smemclr(), which memsets things to zero but does it in such a way that over-clever compilers hopefully won't helpfully optimise the call away if you do it just before freeing something or letting it go out of scope. Use this for (hopefully) every memset whose job is to destroy sensitive data that might otherwise be left lying around in the process's memory. [originally from svn r9586]
2012-07-22 23:51:50 +04:00
smemclr(argv[1], strlen(argv[1]));
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 21:37:15 +04:00
} else {
Since r7265, a user could not launch a PuTTY session to a specific host by simply specifying a hostname on the command line -- this would bring up the config dialog. Use a slightly more sophisticated notion of whether the user meant to launch a session. [originally from svn r7321] [r7265 == 5d76e00dac9220e8798e4d0f17a4069a58ae1667]
2007-02-25 03:50:24 +03:00
/* By default, we bring up the config dialog, rather than launching
* a session. This gets set to TRUE if something happens to change
* that (e.g., a hostname is specified on the command-line). */
int allow_launch = FALSE;
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 22:52:21 +04:00
if (do_cmdline(argc, argv, 0, &allow_launch, inst, 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 21:37:15 +04:00
exit(1); /* pre-defaults pass to get -class */
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 22:52:21 +04:00
do_defaults(NULL, inst->conf);
if (do_cmdline(argc, argv, 1, &allow_launch, inst, 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 21:37:15 +04:00
exit(1); /* post-defaults, do everything */
Ahem. Doing loads of stuff to inst->cfg would probably be best done _after_ allocating inst. Oops. [originally from svn r2571]
2003-01-12 18:45:29 +03: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 22:52:21 +04:00
cmdline_run_saved(inst->conf);
Support for PuTTY-style command-line arguments in Unix PuTTY. I think it's now actually usable as a day-to-day SSH client, even if things like the Event Log are still missing. So I call that a decent lunch hour's work :-) [originally from svn r3034]
2003-03-31 16:10:53 +04:00
Since r7265, a user could not launch a PuTTY session to a specific host by simply specifying a hostname on the command line -- this would bring up the config dialog. Use a slightly more sophisticated notion of whether the user meant to launch a session. [originally from svn r7321] [r7265 == 5d76e00dac9220e8798e4d0f17a4069a58ae1667]
2007-02-25 03:50:24 +03:00
if (loaded_session)
allow_launch = TRUE;
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 22:52:21 +04:00
if ((!allow_launch || !conf_launchable(inst->conf)) &&
!cfgbox(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 21:37:15 +04:00
exit(0); /* config box hit Cancel */
}
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 22:52:50 +03:00
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 21:40:52 +04:00
if (!compound_text_atom)
compound_text_atom = gdk_atom_intern("COMPOUND_TEXT", FALSE);
if (!utf8_string_atom)
utf8_string_atom = gdk_atom_intern("UTF8_STRING", 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-14 03:48:31 +04: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 21:11:17 +03:00
inst->area = gtk_drawing_area_new();
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 11:26:23 +04:00
#if GTK_CHECK_VERSION(2,0,0)
inst->imc = gtk_im_multicontext_new();
#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-14 01:59:10 +04:00
{
char *errmsg = setup_fonts_ucs(inst);
if (errmsg) {
fprintf(stderr, "%s: %s\n", appname, errmsg);
exit(1);
}
}
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 22:07:27 +04:00
init_cutbuffers();
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 22:09:42 +04: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 04:05:37 +04:00
inst->window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
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 22:52:21 +04:00
{
const char *winclass = conf_get_str(inst->conf, CONF_winclass);
if (*winclass)
gtk_window_set_wmclass(GTK_WINDOW(inst->window),
winclass, winclass);
}
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 04:05:37 +04: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 18:31:06 +04:00
/*
* Set up the colour map.
*/
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 16:58:13 +04:00
palette_reset(inst);
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 18:31:06 +04: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 22:52:21 +04: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 22:00:50 +04:00
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 20:02:01 +03:00
{
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
}
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
inst->sbar_adjust = GTK_ADJUSTMENT(gtk_adjustment_new(0,0,0,0,0,0));
inst->sbar = gtk_vscrollbar_new(inst->sbar_adjust);
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04: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 22:00:50 +04:00
/*
* We always create the scrollbar; it remains invisible if
* unwanted, so we can pop it up quickly if it suddenly becomes
* desirable.
*/
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 22:52:21 +04:00
if (conf_get_int(inst->conf, CONF_scrollbar_on_left))
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
gtk_box_pack_start(inst->hbox, inst->sbar, FALSE, FALSE, 0);
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 16:44:01 +04:00
gtk_box_pack_start(inst->hbox, inst->area, TRUE, TRUE, 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 22:52:21 +04:00
if (!conf_get_int(inst->conf, CONF_scrollbar_on_left))
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04: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 13:54:36 +04: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 04:05:37 +04: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 20:45:23 +04:00
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
set_geom_hints(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 20:45:23 +04: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 17:49:12 +04:00
gtk_widget_show(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 22:52:21 +04:00
if (conf_get_int(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 17:49:12 +04:00
gtk_widget_show(inst->sbar);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
else
gtk_widget_hide(inst->sbar);
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 17:49:12 +04:00
gtk_widget_show(GTK_WIDGET(inst->hbox));
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 20:22:05 +03:00
#if GTK_CHECK_VERSION(2,0,0)
if (inst->geometry) {
gtk_window_parse_geometry(GTK_WINDOW(inst->window), inst->geometry);
}
#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 17:49:12 +04: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;
gtk_window_set_position(GTK_WINDOW(inst->window), GTK_WIN_POS_NONE);
gtk_widget_set_uposition(GTK_WIDGET(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 20:22:05 +03: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 17:49:12 +04: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 19:29:02 +03: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);
g_signal_connect(G_OBJECT(inst->area), "configure_event",
G_CALLBACK(configure_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 16:34:19 +03: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 19:29:02 +03: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 16:34:19 +03: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 19:29:02 +03: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-11 00:18:23 +04: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 19:29:02 +03: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-11 00:18:23 +04: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 19:29:02 +03:00
g_signal_connect(G_OBJECT(inst->area), "motion_notify_event",
G_CALLBACK(motion_event), inst);
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);
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 11:26:23 +04:00
#if GTK_CHECK_VERSION(2,0,0)
g_signal_connect(G_OBJECT(inst->imc), "commit",
G_CALLBACK(input_method_commit_event), inst);
#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 22:52:21 +04:00
if (conf_get_int(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 19:29:02 +03: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 20:45:23 +04:00
gtk_widget_add_events(GTK_WIDGET(inst->area),
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 15:24:25 +04:00
GDK_KEY_PRESS_MASK | GDK_KEY_RELEASE_MASK |
GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK |
Support for hiding the mouse pointer on keypresses. Currently activated by `-hide' on the command line. [originally from svn r2045]
2002-10-14 13:58:27 +04:00
GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK);
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 20:45:23 +04:00
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 21:27:00 +03:00
{
extern const char *const *const main_icon[];
extern const int n_main_icon;
set_window_icon(inst->window, main_icon, n_main_icon);
}
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 04:05:37 +04: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 20:45:23 +04: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 16:58:13 +04: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 15:58:59 +04: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 20:05:00 +04:00
/*
* Set up the Ctrl+rightclick context menu.
*/
{
GtkWidget *menuitem;
char *s;
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 21:37:15 +04:00
extern const int use_event_log, new_session, saved_sessions;
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 20:05:00 +04:00
inst->menu = gtk_menu_new();
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 14:57:19 +04: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 19:29:02 +03: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 14:57:19 +04: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)
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 21:37:15 +04:00
if (new_session)
Add a couple of ellipses in Unix context menu (like r759 on Windows). [originally from svn r8649] [r759 == 779069ccd3173cbeee604fd328aac750f5aef466]
2009-09-14 03:37:55 +04:00
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 17:04:18 +04:00
MKMENUITEM("Restart Session", restart_session_menuitem);
inst->restartitem = menuitem;
In Unix PuTTY, grey out "Restart Session" when it doesn't apply (as the Windows version does), rather than hiding it completely. [originally from svn r8650]
2009-09-14 03:41:55 +04:00
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 21:37:15 +04:00
MKMENUITEM("Duplicate Session", dup_session_menuitem);
if (saved_sessions) {
inst->sessionsmenu = gtk_menu_new();
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 05:36:28 +04:00
/* 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);
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 21:37:15 +04:00
gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuitem),
inst->sessionsmenu);
}
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 14:57:19 +04:00
MKSEP();
Add a couple of ellipses in Unix context menu (like r759 on Windows). [originally from svn r8649] [r759 == 779069ccd3173cbeee604fd328aac750f5aef466]
2009-09-14 03:37:55 +04:00
MKMENUITEM("Change Settings...", change_settings_menuitem);
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 14:57:19 +04:00
MKSEP();
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 22:46:45 +04:00
if (use_event_log)
MKMENUITEM("Event Log", event_log_menuitem);
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 14:57:19 +04:00
MKSUBMENU("Special Commands");
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 20:05:00 +04:00
inst->specialsmenu = gtk_menu_new();
gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuitem), inst->specialsmenu);
inst->specialsitem1 = menuitem;
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 14:57:19 +04:00
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 20:05:00 +04:00
inst->specialsitem2 = menuitem;
Telnet specials menu was not being reinstated after a session was restarted in the same window (Windows version only). Policy change: it's now the backend's responsibility to call update_specials_menu() at the start of a session (or whenever it feels ready), if it has any special commands. Otherwise the menu won't be displayed. [originally from svn r4649]
2004-10-17 18:44:27 +04: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 20:05:00 +04:00
MKMENUITEM("Clear Scrollback", clear_scrollback_menuitem);
MKMENUITEM("Reset Terminal", reset_terminal_menuitem);
`Copy All' context-menu item, for what it's worth. [originally from svn r3097]
2003-04-11 21:59:36 +04:00
MKMENUITEM("Copy All", copy_all_menuitem);
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 14:57:19 +04:00
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 20:05:00 +04:00
s = dupcat("About ", appname, NULL);
MKMENUITEM(s, about_menuitem);
sfree(s);
#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 14:57:19 +04: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 20:05:00 +04: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 16:58:13 +04: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 20:05:58 +03: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 16:58:13 +04: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 13:58:27 +04:00
inst->currcursor = inst->textcursor;
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 16:58:13 +04:00
show_mouseptr(inst, 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 14:40:30 +04: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 22:46:45 +04:00
inst->eventlogstuff = eventlogstuff_new();
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 20:06:08 +04:00
request_callback_notifications(notify_toplevel_callback, 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 22:52:21 +04:00
inst->term = term_init(inst->conf, &inst->ucsdata, inst);
inst->logctx = log_init(inst, 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 16:58:13 +04: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 20:11:33 +04:00
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 21:30:14 +03:00
uxsel_init();
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 22:52:21 +04:00
term_size(inst->term, inst->height, inst->width,
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 22:10:25 +04: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 17:04:18 +04: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 16:29:52 +04:00
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 19:12:47 +03:00
ldisc_echoedit_update(inst->ldisc); /* cause ldisc to notice changes */
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 16:29:52 +04:00
RJK's general signal-handling robustness patch. Should fix the weird spin behaviour occasionally seen after pterm's child process dies. [originally from svn r2181]
2002-11-02 17:35:57 +03:00
/* now we're reday to deal with the child exit handler being
* called */
block_signal(SIGCHLD, 0);
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 21:30:14 +03:00
Don't block SIGPIPE until _after_ pterm forks, since otherwise the blockage will propagate to the child process. [originally from svn r3139]
2003-04-25 19:44:01 +04:00
/*
* Block SIGPIPE: if we attempt Duplicate Session or similar
* and it falls over in some way, we certainly don't want
* SIGPIPE terminating the main pterm/PuTTY. Note that we do
* this _after_ (at least pterm) forks off its child process,
* since the child wants SIGPIPE handled in the usual way.
*/
block_signal(SIGPIPE, 1);
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 21:30:14 +03:00
inst->exited = 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 20:45:23 +04:00
gtk_main();
return 0;
}