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

4662 строки
144 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
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
#include "x11misc.h"
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;
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
struct clipboard_data_instance;
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;
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
gboolean sbar_visible;
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
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
/*
* Server-side pixmap which we use to cache the terminal window's
* contents. When we draw text in the terminal, we draw it to this
* pixmap first, and then blit from there to the actual window;
* this way, X expose events can be handled with an absolute
* minimum of network traffic, by just sending a command to
* re-blit an appropriate rectangle from this pixmap.
*/
A sensible minimum of do_text() and do_cursor() is now implemented. This means pterm actually _looks_ like the PuTTY terminal emulator engine, instead of merely giving evidence to the expert eye that said engine is hidden in there somewhere :-) [originally from svn r2011]
2002-10-10 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
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
#ifdef DRAW_TEXT_CAIRO
/*
* If we're drawing using Cairo, we cache the same image on the
* client side in a Cairo surface.
*
* In GTK2+Cairo, this happens _as well_ as having the server-side
* pixmap cache above; in GTK3+Cairo, server-side pixmaps are
* deprecated, so we _just_ have this client-side cache. In the
* latter case that means we have to transmit a big wodge of
* bitmap data over the X connection on every expose event; but
* GTK3 apparently deliberately provides no way to avoid that
* inefficiency, and at least this way we don't _also_ have to
* redo any font rendering just because the window was temporarily
* covered.
*/
cairo_surface_t *surface;
#endif
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 */
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;
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
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;
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
wchar_t *pastein_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
int pastein_data_len;
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
GtkClipboard *clipboard;
struct clipboard_data_instance *current_cdi;
#else
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;
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
#endif
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;
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;
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;
Support smooth scrolling in GTK3. Touchpad gestures can generate much smoother scrolling events than the discrete increments of mouse wheels. GDK3 supports this by means of a new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a floating-point delta value. Added support for this; so in GTK3 mode, you can now touchpad-scroll at a granularity of one line rather than five, but in mouse tracking mode, scroll events are still grouped into 5-line chunks for purposes of turning them into escape sequences to send to the server.
2015-09-25 17:11:44 +03:00
#if GTK_CHECK_VERSION(3,4,0)
gdouble cumulative_scroll;
#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
/* 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;
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
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: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
/* in case we reset this at startup due to a geometry string */
gtk_window_set_gravity(GTK_WINDOW(inst->window), GDK_GRAVITY_NORTH_EAST);
Support for all the server-side window configuration requests, including server-controlled resizing. Irritatingly I've had to use a deprecated option to gtk_window_set_policy() to make this work, resulting in me raising GNOME bug #95818 to ask for it to be un- deprecated again... [originally from svn r2061]
2002-10-15 18:31:06 +04:00
gtk_window_move(GTK_WINDOW(inst->window), x, y);
#else
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 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
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
{
int backing_w = w * inst->font_width + 2*inst->window_border;
int backing_h = h * inst->font_height + 2*inst->window_border;
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
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
if (inst->pixmap) {
gdk_pixmap_unref(inst->pixmap);
inst->pixmap = NULL;
}
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 20:45:23 +04:00
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
inst->pixmap = gdk_pixmap_new(gtk_widget_get_window(widget),
backing_w, backing_h, -1);
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 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
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
#ifdef DRAW_TEXT_CAIRO
if (inst->surface) {
cairo_surface_destroy(inst->surface);
inst->surface = NULL;
}
Change Cairo image surface type from RGB24 to ARGB32. This seems to work around a GTK 3.22 display bug that Colin Watson and I have both observed on Ubuntu (though I found that proxying the X server, e.g. by SSH X forwarding or xtruss, inhibited the bug). The effect of the bug was that the terminal window would appear completely black and nothing would ever be displayed in it, though the terminal session was still actually running and keystrokes would be sent to it. But changing the call to cairo_set_source_surface() to some other cairo_set_source_foo caused successful drawing of whatever other source I selected; the problem seemed specific to the image surface. Also, when I popped up the Ctrl-right-click menu over the terminal window, the menu didn't disappear when dismissed, i.e. the drawing area's redraw operation was not drawing in black, but failing to draw _anything_. That led me to hypothesise that the draw event handler for the terminal drawing area might somehow be accidentally inventing 0 rather than 255 for the implicit alpha channel when using our RGB-type image surface as a source; so I tried setting the surface type to one with an explicit alpha channel in the hope that there would no longer be a need to make up any alpha value at all. And indeed, that seems to solve the problem for me, so I might as well commit it. However, I don't know the full details of what the previous problem was, so this is only an empirical workaround. If it turns out I was making some other mistake without which a RGB source surface would have worked for me, then I should probably revert this and do whatever other fix turns out to be a better plan.
2017-03-08 01:57:54 +03:00
inst->surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32,
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
backing_w, backing_h);
#endif
}
Debian bug #193013 points out that the (default-)one-pixel border is not redrawn when the window background colour is reconfigured mid- session. In addition, the Official Window Background is not reset, meaning that opaque resizes etc will flicker in the old background colour. This checkin should fix both. [originally from svn r3190]
2003-05-13 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;
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
/*
* GTK3 window redraw: we always expect Cairo to be enabled, so
* that inst->surface exists, and pixmaps to be disabled, so that
* inst->pixmap does not exist. Hence, we just blit from
* inst->surface to the window.
*/
if (inst->surface) {
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 16:34:19 +03:00
GdkRectangle dirtyrect;
gdk_cairo_get_clip_rectangle(cr, &dirtyrect);
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
cairo_set_source_surface(cr, inst->surface, 0, 0);
cairo_rectangle(cr, dirtyrect.x, dirtyrect.y,
dirtyrect.width, dirtyrect.height);
cairo_fill(cr);
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
}
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
/*
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
* Draw to the exposed part of the window from the server-side
* backing pixmap.
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 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
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
/*
* Failing that, draw from the client-side Cairo surface. (We
* should never be compiled in a context where we have _neither_
* inst->surface nor inst->pixmap.)
*/
if (inst->surface) {
cairo_t *cr = gdk_cairo_create(gtk_widget_get_window(widget));
cairo_set_source_surface(cr, inst->surface, 0, 0);
cairo_rectangle(cr, event->area.x, event->area.y,
event->area.width, event->area.height);
cairo_fill(cr);
cairo_destroy(cr);
Make the use of server-side backing pixmaps in GTK optional. We won't be able to use them in GTK3, or when compiling with GTK2 and -DGDK_DISABLE_DEPRECATED. This applies to the one we use for the main terminal window, and also the small one we use for the preview pane in the unified font selector.
2015-08-16 11:02:31 +03: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 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)))
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *dup_keyval_name(guint keyval)
{
const char *name = gdk_keyval_name(keyval);
if (name)
return dupstr(name);
else
return dupprintf("UNKNOWN[%u]", (unsigned)keyval);
}
#endif
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 16:53:42 +03:00
static void change_font_size(struct gui_data *inst, int increment);
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 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
{
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
char *type_string, *state_string, *keyval_string, *string_string;
type_string = (event->type == GDK_KEY_PRESS ? dupstr("PRESS") :
event->type == GDK_KEY_RELEASE ? dupstr("RELEASE") :
dupprintf("UNKNOWN[%d]", (int)event->type));
{
static const struct {
int mod_bit;
const char *name;
} mod_bits[] = {
{GDK_SHIFT_MASK, "SHIFT"},
{GDK_LOCK_MASK, "LOCK"},
{GDK_CONTROL_MASK, "CONTROL"},
{GDK_MOD1_MASK, "MOD1"},
{GDK_MOD2_MASK, "MOD2"},
{GDK_MOD3_MASK, "MOD3"},
{GDK_MOD4_MASK, "MOD4"},
{GDK_MOD5_MASK, "MOD5"},
{GDK_SUPER_MASK, "SUPER"},
{GDK_HYPER_MASK, "HYPER"},
{GDK_META_MASK, "META"},
};
int i;
int val = event->state;
state_string = dupstr("");
for (i = 0; i < lenof(mod_bits); i++) {
if (val & mod_bits[i].mod_bit) {
char *old = state_string;
state_string = dupcat(state_string,
state_string[0] ? "|" : "",
mod_bits[i].name,
(char *)NULL);
sfree(old);
val &= ~mod_bits[i].mod_bit;
}
}
if (val || !state_string[0]) {
char *old = state_string;
state_string = dupprintf("%s%s%d", state_string,
state_string[0] ? "|" : "", val);
sfree(old);
}
}
keyval_string = dup_keyval_name(event->keyval);
string_string = dupstr("");
{
int i;
for (i = 0; event->string[i]; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)event->string[i] & 0xFF);
sfree(old);
}
}
debug(("key_event: type=%s keyval=%s state=%s "
"hardware_keycode=%d is_modifier=%s string=[%s]\n",
type_string, keyval_string, state_string,
(int)event->hardware_keycode,
event->is_modifier ? "TRUE" : "FALSE",
string_string));
sfree(type_string);
sfree(state_string);
sfree(keyval_string);
sfree(string_string);
Add conditioned-out diagnostics in GTK key_event(). These should dump out all the important parts of the incoming GdkEventKey, so that if keys aren't being translated right, it should be possible to work out something about why not. To enable: make CPPFLAGS="-DKEY_EVENT_DIAGNOSTICS"
2015-08-27 20:35:17 +03:00
}
#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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - modifier release terminates Alt+numberpad input, "
"keycode = %d\n", inst->alt_keycode));
Support for dead keys and compose sequences on Unix, by instantiating a GtkIMMulticontext and having that filter most keypresses. I think I've got this right so that it doesn't break any previous deliberate keyboard-handling behaviour that's now _after_ the 'if (filter keypress) return' statement. [originally from svn r9567]
2012-06-17 11:26:23 +04:00
#endif
/*
* FIXME: we might usefully try to do something clever here
* about interpreting the generated key code in a way that's
* appropriate to the line code page.
*/
output[0] = inst->alt_keycode;
end = 1;
goto done;
}
#if GTK_CHECK_VERSION(2,0,0)
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - key release, passing to IM\n"));
#endif
if (gtk_im_context_filter_keypress(inst->imc, event)) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - key release accepted by IM\n"));
#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
return TRUE;
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - key release not accepted by IM\n"));
#endif
}
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) {
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - modifier press potentially begins Alt+numberpad "
"input\n"));
#endif
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 {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
int old_keycode = inst->alt_keycode;
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
#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++;
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Alt+numberpad digit %d added to keycode %d"
" gives %d\n", digit, old_keycode, inst->alt_keycode));
Support ALT + numeric keypad for typing in strange character codes. [originally from svn r2071]
2002-10-15 21:18:24 +04:00
#endif
/* Having used this digit, we now do nothing more with it. */
goto done;
}
}
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 16:53:42 +03:00
if (event->keyval == GDK_KEY_greater &&
(event->state & GDK_CONTROL_MASK)) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl->: increase font size\n"));
#endif
change_font_size(inst, +1);
return TRUE;
}
if (event->keyval == GDK_KEY_less &&
(event->state & GDK_CONTROL_MASK)) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl-<: increase font size\n"));
#endif
change_font_size(inst, -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-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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Shift-PgUp scroll\n"));
#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
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl-PgUp scroll\n"));
#endif
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Shift-PgDn scroll\n"));
#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
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl-PgDn scroll\n"));
#endif
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.
*/
Revert accidentally committed breakage of Shift-Ins paste. I turned it into Shift-Return, because I was trying to find out why the former didn't work on OS X and replaced it with something else random to see if the code was even being reached. And then, like an utter doofus, I committed that change as part of a50da0e30.
2015-09-06 11:17:53 +03:00
if (event->keyval == GDK_KEY_Insert &&
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 18:23:54 +03:00
(event->state & GDK_SHIFT_MASK)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Shift-Insert paste\n"));
#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
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);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#else /* !GTK_CHECK_VERSION(2,0,0) */
Turns out that the compose-keys fix in r9567 did in fact break one piece of keyboard handling: if Num Lock is on, numeric keypad keys are eaten by the IM, so we must avoid passing them to the IM in the first place if we're in any non-default numeric keypad mode (application or Nethack). This is a grubby way to do it, but the more obvious approach of just moving the Nethack and app-keypad if statements up to above the IM call doesn't work because those statements depend on the generic Alt-prefix handling that happens just _below_ the IM call. So instead I just repeat the list of keystrokes and modes in an if statement conditionalising the IM call. [originally from svn r9573] [r9567 == 7fc8db15b262ba644b1c7f8e9b89cc5a86f104f2]
2012-07-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 {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
int try_filter = TRUE;
Work around OS X GTK treating Option as an AltGr key. If I'm using Option as the Meta key, I want to suppress OS X GTK's default behaviour of treating it as an AltGr-oid which changes the keyval and Unicode translation of alphabetic keys. So on OS X I enable a somewhat bodgy workaround which retranslates from the hardware keycode as if the Option modifier had not been active at the time, and use that as the character to prefix Esc to. This is a bit nasty because I have to hardwire group = 0 in the call to gdk_keymap_translate_keyboard_state(), whereas in principle what I wanted was group = (whatever would have resulted from everything else in the key event other than MOD1). However, in practice, they seem to be the same, so this will do for the moment.
2015-09-01 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).
*/
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Meta modifier requiring manual intervention, "
"suppressing IM filtering\n"));
#endif
try_filter = FALSE;
}
#endif
if (try_filter) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - general key press, passing to IM\n"));
#endif
if (gtk_im_context_filter_keypress(inst->imc, event)) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - key press accepted by IM\n"));
Work around OS X GTK treating Option as an AltGr key. If I'm using Option as the Meta key, I want to suppress OS X GTK's default behaviour of treating it as an AltGr-oid which changes the keyval and Unicode translation of alphabetic keys. So on OS X I enable a somewhat bodgy workaround which retranslates from the hardware keycode as if the Option modifier had not been active at the time, and use that as the character to prefix Esc to. This is a bit nasty because I have to hardwire group = 0 in the call to gdk_keymap_translate_keyboard_state(), whereas in principle what I wanted was group = (whatever would have resulted from everything else in the key event other than MOD1). However, in practice, they seem to be the same, so this will do for the moment.
2015-09-01 21:10:29 +03:00
#endif
return TRUE;
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - key press not accepted by IM\n"));
#endif
}
}
Turns out that the compose-keys fix in r9567 did in fact break one piece of keyboard handling: if Num Lock is on, numeric keypad keys are eaten by the IM, so we must avoid passing them to the IM in the first place if we're in any non-default numeric keypad mode (application or Nethack). This is a grubby way to do it, but the more obvious approach of just moving the Nethack and app-keypad if statements up to above the IM call doesn't work because those statements depend on the generic Alt-prefix handling that happens just _below_ the IM call. So instead I just repeat the list of keystrokes and modes in an if statement conditionalising the IM call. [originally from svn r9573] [r9567 == 7fc8db15b262ba644b1c7f8e9b89cc5a86f104f2]
2012-07-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);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
{
char *string_string = dupstr("");
int i;
for (i = 0; i < wlen; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%04x", string_string,
string_string[0] ? " " : "",
(unsigned)widedata[i]);
sfree(old);
}
debug((" - string translated into Unicode = [%s]\n",
string_string));
sfree(string_string);
}
#endif
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
wp = widedata;
ulen = charset_from_unicode(&wp, &wlen, output+1, lenof(output)-2,
CS_UTF8, NULL, NULL, 0);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
{
char *string_string = dupstr("");
int i;
for (i = 0; i < ulen; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i+1] & 0xFF);
sfree(old);
}
debug((" - string translated into UTF-8 = [%s]\n",
string_string));
sfree(string_string);
}
#endif
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[1+ulen] = '\0';
}
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#endif /* !GTK_CHECK_VERSION(2,0,0) */
Debian bug #517535: we were unconditionally interpreting the 'string' field in a GdkEventKey structure as ISO-8859-1, which was correct for GTK 1.2 but in 2.0 that field is encoded according to the current C library locale. Hence, we now process that field by converting it to UTF-8 via trips through both libc and libcharset, and then let lpage_send() convert from UTF-8 back to whatever it's supposed to actually go down the line in. [originally from svn r8470]
2009-02-28 19:52:42 +03:00
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;
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - keysym_to_unicode gave %04x\n",
(unsigned)ucsoutput[1]));
#endif
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 = 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);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
{
char *keyval_name = dup_keyval_name(new_keyval);
debug((" - retranslation for manual Meta: "
"new keyval = %s, Unicode = %04x\n",
keyval_name, (unsigned)ucsoutput[1]));
sfree(keyval_name);
}
#endif
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
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl-` special case, translating as 1c\n"));
#endif
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
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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
int orig = output[1];
#endif
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
if (output[1] >= '3' && output[1] <= '7') {
/* ^3,...,^7 map to 0x1B,...,0x1F */
output[1] += '\x1B' - '3';
OS X: fix handling of Ctrl-Space. I'd left it out of my simulated Ctrl processing. It should have been treated as \0, the same as ^2 and ^@.
2015-09-01 21:18:26 +03:00
} else if (output[1] == '2' || output[1] == ' ') {
/* ^2 and ^Space are both ^@, i.e. \0 */
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
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. */
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
if (orig == output[1])
debug((" - manual Ctrl key handling did nothing\n"));
else
debug((" - manual Ctrl key handling: %02x -> %02x\n",
(unsigned)orig, (unsigned)output[1]));
#endif
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
}
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl-Break special case, sending TS_BRK\n"));
#endif
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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Return special case, translating as 0d + special\n"));
#endif
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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl-{space,2,@} special case, translating as 00\n"));
#endif
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
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Ctrl-Shift-space special case, translating as 00a0\n"));
#endif
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
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';
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Backspace, translating as %02x\n",
(unsigned)output[1]));
#endif
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';
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Shift-Backspace, translating as %02x\n",
(unsigned)output[1]));
#endif
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))) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Shift-Tab, translating as ESC [ Z\n"));
#endif
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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Tab, translating as 09\n"));
#endif
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];
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Nethack-mode key"));
#endif
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;
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Application keypad mode key"));
#endif
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]);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - VT52 mode small keypad key"));
#endif
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]);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - SCO mode function key"));
#endif
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]);
}
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - SCO mode small keypad key"));
#endif
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++;
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
if (inst->term->vt52_mode) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - VT52 mode function key"));
#endif
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);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - VT100+ mode function key"));
#endif
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,
"\x1BO%c", code + 'P' - 11 - offt);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
}
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);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - Linux mode F1-F5 function key"));
#endif
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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
if (inst->term->vt52_mode) {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - VT52 mode (overriding xterm) F1-F4 function"
" key"));
#endif
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);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
} else {
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - xterm mode F1-F4 function key"));
#endif
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, "\x1BO%c", code + 'P' - 11);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
}
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)) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - rxvt style Home/End"));
#endif
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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - ordinary function key encoding"));
#endif
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[%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);
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
debug((" - arrow key"));
#endif
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) {
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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i] & 0xFF);
sfree(old);
}
debug((" - final output, special, generic encoding = [%s]\n",
charset_to_localenc(output_charset), string_string));
sfree(string_string);
#endif
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
/*
* 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) {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i] & 0xFF);
sfree(old);
}
debug((" - final output in %s = [%s]\n",
charset_to_localenc(output_charset), string_string));
sfree(string_string);
#endif
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 {
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%04x", string_string,
string_string[0] ? " " : "",
(unsigned)ucsoutput[i]);
sfree(old);
}
debug((" - final output in Unicode = [%s]\n",
string_string));
sfree(string_string);
#endif
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
/*
* 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.
*/
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = start; i < end; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)output[i] & 0xFF);
sfree(old);
}
debug((" - final output in direct-to-font encoding = [%s]\n",
string_string));
sfree(string_string);
#endif
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;
Clean up GTK keyboard event diagnostics. When I introduced the KEY_EVENT_DIAGNOSTICS system last month in commit 769600b22, I somehow didn't notice that it sat next to an existing system of ifdefs labelled KEY_DEBUGGING, which did some things worse but some things better. Now I've expanded both of those into a fairly complete system of diagnostics (keeping the newer name of KEY_EVENT_DIAGNOSTICS), and made them use debug() rather than printf() so that in situations where no standard output is available I can still retrieve the diagnostics from debug.log.
2015-09-06 11:13:48 +03:00
#ifdef KEY_EVENT_DIAGNOSTICS
char *string_string = dupstr("");
int i;
for (i = 0; str[i]; i++) {
char *old = string_string;
string_string = dupprintf("%s%s%02x", string_string,
string_string[0] ? " " : "",
(unsigned)str[i] & 0xFF);
sfree(old);
}
debug((" - IM commit event in UTF-8 = [%s]\n", string_string));
sfree(string_string);
#endif
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
Support smooth scrolling in GTK3. Touchpad gestures can generate much smoother scrolling events than the discrete increments of mouse wheels. GDK3 supports this by means of a new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a floating-point delta value. Added support for this; so in GTK3 mode, you can now touchpad-scroll at a granularity of one line rather than five, but in mouse tracking mode, scroll events are still grouped into 5-line chunks for purposes of turning them into escape sequences to send to the server.
2015-09-25 17:11:44 +03:00
#define SCROLL_INCREMENT_LINES 5
#if GTK_CHECK_VERSION(3,4,0)
gboolean scroll_internal(struct gui_data *inst, gdouble delta, guint state,
gdouble ex, gdouble ey)
{
int shift, ctrl, alt, x, y, raw_mouse_mode;
show_mouseptr(inst, 1);
shift = state & GDK_SHIFT_MASK;
ctrl = state & GDK_CONTROL_MASK;
alt = state & inst->meta_mod_mask;
x = (ex - inst->window_border) / inst->font_width;
y = (ey - inst->window_border) / inst->font_height;
raw_mouse_mode =
send_raw_mouse && !(shift && conf_get_int(inst->conf,
CONF_mouse_override));
inst->cumulative_scroll += delta * SCROLL_INCREMENT_LINES;
if (!raw_mouse_mode) {
int scroll_lines = (int)inst->cumulative_scroll; /* rounds toward 0 */
if (scroll_lines) {
term_scroll(inst->term, 0, scroll_lines);
inst->cumulative_scroll -= scroll_lines;
}
return TRUE;
} else {
int scroll_events = (int)(inst->cumulative_scroll /
SCROLL_INCREMENT_LINES);
if (scroll_events) {
int button;
inst->cumulative_scroll -= scroll_events * SCROLL_INCREMENT_LINES;
if (scroll_events > 0) {
button = MBT_WHEEL_DOWN;
} else {
button = MBT_WHEEL_UP;
scroll_events = -scroll_events;
}
while (scroll_events-- > 0) {
term_mouse(inst->term, button, translate_button(button),
MA_CLICK, x, y, shift, ctrl, alt);
}
}
return TRUE;
}
}
#endif
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
static gboolean button_internal(struct gui_data *inst, GdkEventButton *event)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 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. */
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
inst->input_event_time = event->time;
Richard Boulton's patch for improved correctness in selection handling (generally, selection request timestamps should be set to the timestamp on the event that caused them). [originally from svn r3408]
2003-08-21 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
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
shift = event->state & GDK_SHIFT_MASK;
ctrl = event->state & GDK_CONTROL_MASK;
alt = event->state & inst->meta_mod_mask;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 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) {
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
if (event->button == 4 && event->type == GDK_BUTTON_PRESS) {
Support smooth scrolling in GTK3. Touchpad gestures can generate much smoother scrolling events than the discrete increments of mouse wheels. GDK3 supports this by means of a new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a floating-point delta value. Added support for this; so in GTK3 mode, you can now touchpad-scroll at a granularity of one line rather than five, but in mouse tracking mode, scroll events are still grouped into 5-line chunks for purposes of turning them into escape sequences to send to the server.
2015-09-25 17:11:44 +03:00
term_scroll(inst->term, 0, -SCROLL_INCREMENT_LINES);
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
return TRUE;
}
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
if (event->button == 5 && event->type == GDK_BUTTON_PRESS) {
Support smooth scrolling in GTK3. Touchpad gestures can generate much smoother scrolling events than the discrete increments of mouse wheels. GDK3 supports this by means of a new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a floating-point delta value. Added support for this; so in GTK3 mode, you can now touchpad-scroll at a granularity of one line rather than five, but in mouse tracking mode, scroll events are still grouped into 5-line chunks for purposes of turning them into escape sequences to send to the server.
2015-09-25 17:11:44 +03:00
term_scroll(inst->term, 0, +SCROLL_INCREMENT_LINES);
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
return TRUE;
}
}
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
if (event->button == 3 && ctrl) {
#if GTK_CHECK_VERSION(3,22,0)
gtk_menu_popup_at_pointer(GTK_MENU(inst->menu), (GdkEvent *)event);
#else
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,
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
event->button, event->time);
#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
return TRUE;
}
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
if (event->button == 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;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
else if (event->button == 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;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
else if (event->button == 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;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
else if (event->button == 4)
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
button = MBT_WHEEL_UP;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
else if (event->button == 5)
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
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! */
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
switch (event->type) {
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 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 */
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03: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), 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;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
return button_internal(inst, event);
Manfred Schwarb points out that scroll wheel support stopped working with the switch to GTK2. This turns out to be because, where GTK1 represented the scroll wheel as mouse buttons 4 and 5 and generated GdkEventButton when it was moved, GTK2 has moved wheel actions out into a new event type GdkEventScroll which we were not handling. Now we do, so scroll wheel support should be back in place. [originally from svn r8063]
2008-06-11 00:18:23 +04:00
}
#if GTK_CHECK_VERSION(2,0,0)
/*
* In GTK 2, mouse wheel events have become a new type of event.
* This handler translates them back into button-4 and button-5
* presses so that I don't have to change my old code too much :-)
*/
gboolean scroll_event(GtkWidget *widget, GdkEventScroll *event, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
Support smooth scrolling in GTK3. Touchpad gestures can generate much smoother scrolling events than the discrete increments of mouse wheels. GDK3 supports this by means of a new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a floating-point delta value. Added support for this; so in GTK3 mode, you can now touchpad-scroll at a granularity of one line rather than five, but in mouse tracking mode, scroll events are still grouped into 5-line chunks for purposes of turning them into escape sequences to send to the server.
2015-09-25 17:11:44 +03:00
#if GTK_CHECK_VERSION(3,4,0)
gdouble dx, dy;
if (gdk_event_get_scroll_deltas((GdkEvent *)event, &dx, &dy)) {
return scroll_internal(inst, dy, event->state, event->x, event->y);
} else
return FALSE;
#else
guint button;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
GdkEventButton *event_button;
gboolean ret;
Manfred Schwarb points out that scroll wheel support stopped working with the switch to GTK2. This turns out to be because, where GTK1 represented the scroll wheel as mouse buttons 4 and 5 and generated GdkEventButton when it was moved, GTK2 has moved wheel actions out into a new event type GdkEventScroll which we were not handling. Now we do, so scroll wheel support should be back in place. [originally from svn r8063]
2008-06-11 00:18:23 +04:00
if (event->direction == GDK_SCROLL_UP)
button = 4;
else if (event->direction == GDK_SCROLL_DOWN)
button = 5;
else
return FALSE;
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
event_button = (GdkEventButton *)gdk_event_new(GDK_BUTTON_PRESS);
Stop Gtk2 builds exploding on scroll wheel events. More fallout from 64221972c.
2017-05-20 14:44:56 +03:00
event_button->window = g_object_ref(event->window);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
event_button->send_event = event->send_event;
event_button->time = event->time;
event_button->x = event->x;
event_button->y = event->y;
event_button->axes = NULL;
event_button->state = event->state;
event_button->button = button;
Stop Gtk2 builds exploding on scroll wheel events. More fallout from 64221972c.
2017-05-20 14:44:56 +03:00
event_button->device = g_object_ref(event->device);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
event_button->x_root = event->x_root;
event_button->y_root = event->y_root;
ret = button_internal(inst, event_button);
Add a cast to fix a warning. This fixes compilation with Gtk 2 with -Werror. Problem introduced by 64221972c.
2017-04-30 13:39:07 +03:00
gdk_event_free((GdkEvent *)event_button);
Handle deprecation of gtk_menu_popup GTK+ 3.22 deprecates gtk_menu_popup in favour of various gtk_menu_popup_at_* functions. gtk_menu_popup_at_pointer seems most appropriate, but that requires being able to pass it a GdkEvent rather than just some elements of it. In order to achieve that, I've rearranged the scroll_event shim to construct a real GdkEventButton and pass that down to button_internal.
2017-03-06 00:41:21 +03:00
return ret;
Support smooth scrolling in GTK3. Touchpad gestures can generate much smoother scrolling events than the discrete increments of mouse wheels. GDK3 supports this by means of a new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a floating-point delta value. Added support for this; so in GTK3 mode, you can now touchpad-scroll at a granularity of one line rather than five, but in mouse tracking mode, scroll events are still grouped into 5-line chunks for purposes of turning them into escape sequences to send to the server.
2015-09-25 17:11:44 +03: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
}
#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
}
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
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
}
GTK: stop using geometry-based window sizing functions. gtk_window_resize_to_geometry and gtk_window_set_default_geometry are deprecated as of GTK 3.20, so now we do the geometry -> pixel size conversion on our side.
2016-04-04 13:24:24 +03:00
#if GTK_CHECK_VERSION(2,0,0)
static void compute_whole_window_size(struct gui_data *inst,
int wchars, int hchars,
int *wpix, int *hpix);
#endif
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +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
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) */
GTK: stop using geometry-based window sizing functions. gtk_window_resize_to_geometry and gtk_window_set_default_geometry are deprecated as of GTK 3.20, so now we do the geometry -> pixel size conversion on our side.
2016-04-04 13:24:24 +03:00
int wp, hp;
compute_whole_window_size(inst, w, h, &wp, &hp);
gtk_window_resize(GTK_WINDOW(inst->window), wp, hp);
Use new GTK3 API call for server-controlled window resize. gtk_window_resize_to_geometry() allows us to make use of the already- set-up WM resize hints to immediately figure out how to resize the window to a particular character cell size, and hence makes a much simpler implementation of request_resize() than the previous hackery.
2015-08-24 20:59:13 +03: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
}
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
#if GTK_CHECK_VERSION(3,0,0)
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-06 00:45:04 +03:00
char *colour_to_css(const GdkColor *col)
{
Stop using GTK3-deprecated gdk_window_set_background(). We now have to use gdk_window_set_background_rgba(), having first set up an appropriate GdkRGBA structure.
2015-08-22 16:11:45 +03:00
GdkRGBA rgba;
rgba.red = col->red / 65535.0;
rgba.green = col->green / 65535.0;
rgba.blue = col->blue / 65535.0;
rgba.alpha = 1.0;
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-06 00:45:04 +03:00
return gdk_rgba_to_string(&rgba);
}
#endif
void set_gtk_widget_background(GtkWidget *widget, const GdkColor *col)
{
#if GTK_CHECK_VERSION(3,0,0)
GtkCssProvider *provider = gtk_css_provider_new();
char *col_css = colour_to_css(col);
char *data = dupprintf(
"#drawing-area, #top-level { background-color: %s; }\n", col_css);
gtk_css_provider_load_from_data(provider, data, -1, NULL);
GtkStyleContext *context = gtk_widget_get_style_context(widget);
gtk_style_context_add_provider(context, GTK_STYLE_PROVIDER(provider),
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
free(data);
free(col_css);
Stop using GTK3-deprecated gdk_window_set_background(). We now have to use gdk_window_set_background_rgba(), having first set up an appropriate GdkRGBA structure.
2015-08-22 16:11:45 +03:00
#else
Fix thinko introduced in 8833634f4. This prevented compilation with Gtk 2.
2017-04-30 13:01:13 +03:00
if (gtk_widget_get_window(widget)) {
Compile fixes for GTK1 after recent work. The whole of get_label_text_dimensions() should have been outside the GTK 2 ifdef; I'd left a gtk_label_set_width_chars() unconditional; and GDK1's gdk_window_set_background() lacks a const in its prototype. Serves me right for not test-compiling in all three versions!
2015-08-25 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;
Fix thinko introduced in 8833634f4. This prevented compilation with Gtk 2.
2017-04-30 13:01:13 +03:00
gdk_window_set_background(gtk_widget_get_window(widget), &col_mutable);
Compile fixes for GTK1 after recent work. The whole of get_label_text_dimensions() should have been outside the GTK 2 ifdef; I'd left a gtk_label_set_width_chars() unconditional; and GDK1's gdk_window_set_background() lacks a const in its prototype. Serves me right for not test-compiling in all three versions!
2015-08-25 21:50:23 +03: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
#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
{
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-06 00:45:04 +03:00
if (inst->area)
set_gtk_widget_background(GTK_WIDGET(inst->area), &inst->cols[258]);
if (inst->window)
set_gtk_widget_background(GTK_WIDGET(inst->window), &inst->cols[258]);
Fix the nasty flashing-light-grey-on-resize problem, after MCV helpfully alerted me to the existence of gdk_window_set_background(). [originally from svn r2129]
2002-10-25 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
}
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
#ifdef JUST_USE_GTK_CLIPBOARD_UTF8
/* ----------------------------------------------------------------------
* Clipboard handling, using the high-level GtkClipboard interface in
* as hands-off a way as possible. We write and read the clipboard as
* UTF-8 text, and let GTK deal with converting to any other text
* formats it feels like.
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 22:07:27 +04:00
*/
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
void init_clipboard(struct gui_data *inst)
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 22:07:27 +04:00
{
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
inst->clipboard = gtk_clipboard_get_for_display(gdk_display_get_default(),
DEFAULT_CLIPBOARD);
}
/*
* Because calling gtk_clipboard_set_with_data triggers a call to the
* clipboard_clear function from the last time, we need to arrange a
* way to distinguish a real call to clipboard_clear for the _new_
* instance of the clipboard data from the leftover call for the
* outgoing one. We do this by setting the user data field in our
* gtk_clipboard_set_with_data() call, instead of the obvious pointer
* to 'inst', to one of these.
*/
struct clipboard_data_instance {
struct gui_data *inst;
char *pasteout_data_utf8;
int pasteout_data_utf8_len;
};
static void clipboard_provide_data(GtkClipboard *clipboard,
GtkSelectionData *selection_data,
guint info, gpointer data)
{
struct clipboard_data_instance *cdi =
(struct clipboard_data_instance *)data;
struct gui_data *inst = cdi->inst;
if (inst->current_cdi == cdi) {
gtk_selection_data_set_text(selection_data, cdi->pasteout_data_utf8,
cdi->pasteout_data_utf8_len);
}
}
static void clipboard_clear(GtkClipboard *clipboard, gpointer data)
{
struct clipboard_data_instance *cdi =
(struct clipboard_data_instance *)data;
struct gui_data *inst = cdi->inst;
if (inst->current_cdi == cdi) {
term_deselect(inst->term);
inst->current_cdi = NULL;
}
sfree(cdi->pasteout_data_utf8);
sfree(cdi);
}
void write_clip(void *frontend, wchar_t *data, int *attr, int len,
int must_deselect)
{
struct gui_data *inst = (struct gui_data *)frontend;
struct clipboard_data_instance *cdi;
if (inst->direct_to_font) {
/* In this clipboard mode, we just can't paste if we're in
* direct-to-font mode. Fortunately, that shouldn't be
* important, because we'll only use this clipboard handling
* code on systems where that kind of font doesn't exist
* anyway. */
return;
}
cdi = snew(struct clipboard_data_instance);
cdi->inst = inst;
inst->current_cdi = cdi;
cdi->pasteout_data_utf8 = snewn(len*6, char);
{
const wchar_t *tmp = data;
int tmplen = len;
cdi->pasteout_data_utf8_len =
charset_from_unicode(&tmp, &tmplen, cdi->pasteout_data_utf8,
len*6, CS_UTF8, NULL, NULL, 0);
}
/*
* It would be nice to just call gtk_clipboard_set_text() in place
* of all of the faffing below. Unfortunately, that won't give me
* access to the clipboard-clear event, which we use to visually
* deselect text in the terminal.
*/
{
GtkTargetList *targetlist;
GtkTargetEntry *targettable;
gint n_targets;
targetlist = gtk_target_list_new(NULL, 0);
gtk_target_list_add_text_targets(targetlist, 0);
targettable = gtk_target_table_new_from_list(targetlist, &n_targets);
gtk_clipboard_set_with_data(inst->clipboard, targettable, n_targets,
clipboard_provide_data, clipboard_clear,
cdi);
gtk_target_table_free(targettable, n_targets);
gtk_target_list_unref(targetlist);
}
}
static void clipboard_text_received(GtkClipboard *clipboard,
const gchar *text, gpointer data)
{
struct gui_data *inst = (struct gui_data *)data;
int length;
if (!text)
return;
length = strlen(text);
if (inst->pastein_data)
sfree(inst->pastein_data);
inst->pastein_data = snewn(length, wchar_t);
inst->pastein_data_len = mb_to_wc(CS_UTF8, 0, text, length,
inst->pastein_data, length);
term_do_paste(inst->term);
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
}
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
void request_paste(void *frontend)
{
struct gui_data *inst = (struct gui_data *)frontend;
gtk_clipboard_request_text(inst->clipboard, clipboard_text_received, inst);
}
#else /* JUST_USE_GTK_CLIPBOARD_UTF8 */
/* ----------------------------------------------------------------------
* Clipboard handling for X, using the low-level gtk_selection_*
* interface, handling conversions to fiddly things like compound text
* ourselves, and storing in X cut buffers too.
*
* This version of the clipboard code has to be kept around for GTK1,
* which doesn't have the higher-level GtkClipboard interface at all.
* And since it works on GTK2 and GTK3 too and has had a good few
* years of shakedown and bug fixing, we might as well keep using it
* where it's applicable.
*
* It's _possible_ that we might be able to replicate all the
* important wrinkles of this code in GtkClipboard. (In particular,
* cut buffers or local analogue look as if they might be accessible
* via gtk_clipboard_set_can_store(), and delivering text in
* non-Unicode formats only in the direct-to-font case ought to be
* possible if we can figure out the right set of things to put in the
* GtkTargetList.) But that work can wait until there's a need for it!
*/
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. */
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
static void store_cutbuffer(char * ptr, int len)
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 22:07:27 +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
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().
*/
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
static char *retrieve_cutbuffer(int *nbytes)
Richard B's patch to support X cut buffers as well as ordinary selections, meaning that (a) a pterm can leave copied text in the cut buffer after it terminates so that applications can pick it up even though it isn't still around to deliver the selection in person, and (b) pterm can pick up things left in this way by other apps. Downside is that all of this only happens in ISO8859-1, because X is weird like that. [originally from svn r3409]
2003-08-21 22:07:27 +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
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
}
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +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
}
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
static void selection_get(GtkWidget *widget, GtkSelectionData *seldata,
guint info, guint time_stamp, gpointer data)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 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;
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
}
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
static gint selection_clear(GtkWidget *widget, GdkEventSelection *seldata,
gpointer data)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 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;
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
}
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
static void selection_received(GtkWidget *widget, GtkSelectionData *seldata,
guint time, gpointer data)
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 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
}
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
void init_clipboard(struct gui_data *inst)
{
#ifndef NOT_X_WINDOWS
/*
* Ensure that all the cut buffers exist - according to the ICCCM,
* we must do this before we start using cut buffers.
*/
unsigned char empty[] = "";
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER0, XA_STRING, 8, PropModeAppend, empty, 0);
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER1, XA_STRING, 8, PropModeAppend, empty, 0);
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER2, XA_STRING, 8, PropModeAppend, empty, 0);
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER3, XA_STRING, 8, PropModeAppend, empty, 0);
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER4, XA_STRING, 8, PropModeAppend, empty, 0);
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER5, XA_STRING, 8, PropModeAppend, empty, 0);
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER6, XA_STRING, 8, PropModeAppend, empty, 0);
Ignore X11 BadMatch errors during cut buffer setup. This is quite a pain, since it involves inventing an entire new piece of infrastructure to install a custom Xlib error handler and give it a queue of things to do. But it fixes a bug in which Unix pterm/PuTTY crash out at startup if one of the root window's CUT_BUFFERn properties contains something of a type other than STRING - in particular, UTF8_STRING is not unheard-of. For example, run xprop -root -format CUT_BUFFER3 8u -set CUT_BUFFER3 "thingy" and then pterm without this fix would have crashed.
2016-03-20 21:16:43 +03:00
x11_ignore_error(disp, BadMatch);
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
XChangeProperty(disp, GDK_ROOT_WINDOW(),
XA_CUT_BUFFER7, XA_STRING, 8, PropModeAppend, empty, 0);
#endif
g_signal_connect(G_OBJECT(inst->area), "selection_received",
G_CALLBACK(selection_received), inst);
g_signal_connect(G_OBJECT(inst->area), "selection_get",
G_CALLBACK(selection_get), inst);
g_signal_connect(G_OBJECT(inst->area), "selection_clear_event",
G_CALLBACK(selection_clear), inst);
}
/*
* End of selection/clipboard handling.
* ----------------------------------------------------------------------
*/
#endif /* JUST_USE_GTK_CLIPBOARD_UTF8 */
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;
Compile fix for GTK 3.18: avoid gtk_adjustment_changed(). That function is deprecated as of 3.18, on the basis that GTK doesn't need telling any more when the adjustment's owning widget needs updating. So we just need to condition out the call.
2016-04-03 12:10:40 +03:00
#if !GTK_CHECK_VERSION(3,18,0)
Scrollbar now exists and functions; so do Shift-PgUp / Shift-PgDn. [originally from svn r2031]
2002-10-13 13:54:36 +04:00
gtk_adjustment_changed(inst->sbar_adjust);
Compile fix for GTK 3.18: avoid gtk_adjustment_changed(). That function is deprecated as of 3.18, on the basis that GTK doesn't need telling any more when the adjustment's owning widget needs updating. So we just need to condition out the call.
2016-04-03 12:10:40 +03:00
#endif
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
}
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
static void show_scrollbar(struct gui_data *inst, gboolean visible)
{
inst->sbar_visible = visible;
if (visible)
gtk_widget_show(inst->sbar);
else
gtk_widget_hide(inst->sbar);
}
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
{
/*
Remove a couple of outdated FIXME comments. I had originally planned to implement a Compose-type key locally in GTK PuTTY, as I did in Windows PuTTY. But in fact we've done this for some time by delegating to the GTK IM system, which is a far better idea anyway. So there's no point any more having the FIXME comment that mentions Compose keys. Also, there was a comment worrying about what I was going to do about double-width characters in Pango, which is long since sorted out.
2015-09-26 14:59:26 +03:00
* In this front end, double-width characters are handled using a
* separate font, so this can safely just return 1 always.
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 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;
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
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) {
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
/* If we're doing GDK-based drawing, then we also expect
* inst->pixmap to exist. */
dctx->uctx.u.gdk.target = inst->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
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);
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
/* If we're doing Cairo drawing, we expect inst->surface to
* exist, and we draw to that first, regardless of whether we
* subsequently copy the results to inst->pixmap. */
dctx->uctx.u.cairo.cr = cairo_create(inst->surface);
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 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)
{
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
#if defined DRAW_TEXT_CAIRO && !defined 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_CAIRO) {
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
/*
* If inst->surface and inst->pixmap both exist, then we've
* just drawn new content to the former which we must copy to
* the latter.
*/
cairo_t *cr = gdk_cairo_create(dctx->inst->pixmap);
cairo_set_source_surface(cr, dctx->inst->surface, 0, 0);
cairo_rectangle(cr, x, y, w, h);
cairo_fill(cr);
cairo_destroy(cr);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 23:05:56 +03:00
}
#endif
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
/*
* Now we just queue a window redraw, which will cause
* inst->surface or inst->pixmap (whichever is appropriate for our
* compile mode) to be copied to the real window when we receive
* the resulting "expose" or "draw" event.
*
* Amazingly, this one API call is actually valid in all versions
* of GTK :-)
*/
gtk_widget_queue_draw_area(dctx->inst->area, x, y, w, h);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 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);
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
int w = inst->width * inst->font_width + 2*inst->window_border;
int h = inst->height * inst->font_height + 2*inst->window_border;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 23:05:56 +03:00
draw_set_colour(dctx, 258);
Use a Cairo image surface as a client-side cache. In any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo image surface which lives on the client; then we either blit directly from that to the window (if we're in GTK3 mode, or GTK2 without deprecated pieces of API), or else we blit from the Cairo surface to the server-side pixmap and then from there to the actual window. In DRAWTYPE_GDK mode, nothing much has changed: we still draw directly to the server-side pixmap using the GDK drawing API, then blit from there to the window. But there is one change, namely that the blit is no longer done proactively - instead, we queue a redraw of the affected rectangle, and wait until we're called back by the expose handler. The main aim of all this is to arrange that the only time we ever draw to the real window is in response to expose/draw events. The experimental GTK3 OS X port stopped working a week or two ago (I presume in response to an OS update) with the symptoms that attempts to draw on the window outside the context of a "draw" event handler just didn't seem to work any more; this change fixes it. In addition to that benefit, this change also has obvious performance advantages in principle. No more expensive text rendering in response to an expose event - just re-copy to the window from the bitmap we already have, from wherever it's stored that's nearest. Moreover, this seems to have fixed the significant performance problem with X server-side fonts under GTK. I didn't expect _that_! I'd guessed that the approach of downloading character bitmaps and rendering them manually via Cairo was just inherently slow for some reason. I've no real idea _why_ this change improves matters so much; my best guess is that perhaps there's an overhead in each drawing operation to a GDK Cairo surface, so we win by doing lots of operations to a much faster image surface and then batching them up into one GDK Cairo operation. But whyever it is, I'm certainly not complaining! (In fact, it now seems to be noticeably _faster_, at least on my usual local X displays, to draw server-side fonts using that technique than using the old GDK approach. I may yet decide to switch over...)
2015-09-24 16:08:25 +03:00
draw_rectangle(dctx, 1, 0, 0, w, h);
draw_update(dctx, 0, 0, w, h);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 23:05:56 +03:00
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;
Fix combining character handling in Pango. The top-level loop in gtkwin.c which draws text was expecting that the right way to draw a printing character plus combining characters was to overprint them one by one on top of each other. This is an OK assumption for X bitmap fonts, but in Pango, it works very badly - most obviously because asking Pango to display a combining char on its own causes it to print a dotted circle representing the base char, but also because surely there will be character combinations where Pango wants to do something more sophisticated than just printing them each at a standard offset, and it would be a shame not to let it. So I've moved the previous overprinting loop down into the x11font subclass of the unifont mechanism. The top-level gtkwin.c drawing code now calls a new method unifont_draw_combining, which in the X11 case does the same loop as before, but in the Pango case, just passes a whole base+combinings string to Pango in one go and lets it do the best job it can.
2015-09-26 12:18:53 +03:00
int ncombining;
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);
Fix combining character handling in Pango. The top-level loop in gtkwin.c which draws text was expecting that the right way to draw a printing character plus combining characters was to overprint them one by one on top of each other. This is an OK assumption for X bitmap fonts, but in Pango, it works very badly - most obviously because asking Pango to display a combining char on its own causes it to print a dotted circle representing the base char, but also because surely there will be character combinations where Pango wants to do something more sophisticated than just printing them each at a standard offset, and it would be a shame not to let it. So I've moved the previous overprinting loop down into the x11font subclass of the unifont mechanism. The top-level gtkwin.c drawing code now calls a new method unifont_draw_combining, which in the X11 case does the same loop as before, but in the Pango case, just passes a whole base+combinings string to Pango in one go and lets it do the best job it can.
2015-09-26 12:18:53 +03:00
if (ncombining > 1) {
assert(len == 1);
unifont_draw_combining(&dctx->uctx, inst->fonts[fontid],
x*inst->font_width+inst->window_border,
(y*inst->font_height+inst->window_border+
inst->fonts[0]->ascent),
text, ncombining, widefactor > 1,
bold, inst->font_width);
} else {
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,
Fix combining character handling in Pango. The top-level loop in gtkwin.c which draws text was expecting that the right way to draw a printing character plus combining characters was to overprint them one by one on top of each other. This is an OK assumption for X bitmap fonts, but in Pango, it works very badly - most obviously because asking Pango to display a combining char on its own causes it to print a dotted circle representing the base char, but also because surely there will be character combinations where Pango wants to do something more sophisticated than just printing them each at a standard offset, and it would be a shame not to let it. So I've moved the previous overprinting loop down into the x11font subclass of the unifont mechanism. The top-level gtkwin.c drawing code now calls a new method unifont_draw_combining, which in the X11 case does the same loop as before, but in the Pango case, just passes a whole base+combinings string to Pango in one go and lets it do the best job it can.
2015-09-26 12:18:53 +03:00
(y*inst->font_height+inst->window_border+
inst->fonts[0]->ascent),
text, len, widefactor > 1,
Change the unifont API so that text is passed right down to the individual font implementation as wchar_t, rather than having to be converted by the client into the appropriate MBCS/SBCS. This also means I can remove 'real_charset' from the public-facing contents of the unifont structure. [originally from svn r9292]
2011-09-16 23:18:53 +04:00
bold, inst->font_width);
First draft of Unicode support in pterm. It's pretty complete: it does UTF-8 copy and paste (falling back to normal strings if necessary), it understands X font encodings and translates things accordingly so that if you have a Unicode font you can ask for virtually any single-byte encoding and get it (Mac-Roman pterm, anyone?), and so on. There's work left to be done (wide fonts for CJK spring to mind), but I reckon this is a pretty good start. [originally from svn r2395]
2002-12-31 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
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
}
Account for GtkApplicationWindow menu bar in geometry hints. This is another widget that can appear in the top-level window, in addition to the drawing area and scrollbar we put there ourselves, and hence which needs to be accounted for when figuring out the relationship between the drawing area size in character cells and the full window size in pixels. Finding the menu bar widget itself is a bit of a hassle, but having found it, dealing with it is basically the same as dealing with the scrollbar, only with x and y swapped.
2016-04-04 13:28:34 +03:00
#if GTK_CHECK_VERSION(3,0,0)
struct find_app_menu_bar_ctx {
GtkWidget *area, *menubar;
};
static void find_app_menu_bar(GtkWidget *widget, gpointer data)
{
struct find_app_menu_bar_ctx *ctx = (struct find_app_menu_bar_ctx *)data;
if (widget != ctx->area && GTK_IS_MENU_BAR(widget))
ctx->menubar = widget;
}
#endif
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
static void compute_geom_hints(struct gui_data *inst, GdkGeometry *geom)
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
{
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
/*
* Unused fields in geom.
*/
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
geom->max_width = geom->max_height = -1;
geom->min_aspect = geom->max_aspect = 0;
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
/*
* Set up the geometry fields we care about, with reference to
Account for GtkApplicationWindow menu bar in geometry hints. This is another widget that can appear in the top-level window, in addition to the drawing area and scrollbar we put there ourselves, and hence which needs to be accounted for when figuring out the relationship between the drawing area size in character cells and the full window size in pixels. Finding the menu bar widget itself is a bit of a hassle, but having found it, dealing with it is basically the same as dealing with the scrollbar, only with x and y swapped.
2016-04-04 13:28:34 +03:00
* just the drawing area. We'll correct for other widgets in a
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
* moment.
*/
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
geom->min_width = inst->font_width + 2*inst->window_border;
geom->min_height = inst->font_height + 2*inst->window_border;
geom->base_width = 2*inst->window_border;
geom->base_height = 2*inst->window_border;
geom->width_inc = inst->font_width;
geom->height_inc = inst->font_height;
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
/*
* If we've got a scrollbar visible, then we must include its
* width as part of the base and min width, and also ensure that
* our window's minimum height is at least the height required by
* the scrollbar.
*
* In the latter case, we must also take care to arrange that
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
* (geom->min_height - geom->base_height) is an integer multiple of
* geom->height_inc, because if it's not, then some window managers
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
* (we know of xfwm4) get confused, with the effect that they
* resize our window to a height based on min_height instead of
* base_height, which we then round down and the window ends up
* too short.
*/
if (inst->sbar_visible) {
GtkRequisition req;
int min_sb_height;
#if GTK_CHECK_VERSION(3,0,0)
gtk_widget_get_preferred_size(inst->sbar, &req, NULL);
#else
gtk_widget_size_request(inst->sbar, &req);
#endif
/* Compute rounded-up scrollbar height. */
min_sb_height = req.height;
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
min_sb_height += geom->height_inc - 1;
min_sb_height -= ((min_sb_height - geom->base_height%geom->height_inc)
% geom->height_inc);
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
geom->min_width += req.width;
geom->base_width += req.width;
if (geom->min_height < min_sb_height)
geom->min_height = min_sb_height;
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
}
Account for GtkApplicationWindow menu bar in geometry hints. This is another widget that can appear in the top-level window, in addition to the drawing area and scrollbar we put there ourselves, and hence which needs to be accounted for when figuring out the relationship between the drawing area size in character cells and the full window size in pixels. Finding the menu bar widget itself is a bit of a hassle, but having found it, dealing with it is basically the same as dealing with the scrollbar, only with x and y swapped.
2016-04-04 13:28:34 +03:00
#if GTK_CHECK_VERSION(3,0,0)
/*
* And if we're running a gtkapp.c based program and
* GtkApplicationWindow has given us a menu bar inside the window,
* then we must take that into account as well.
*
* In its unbounded wisdom, GtkApplicationWindow doesn't actually
* give us a direct function call to _find_ the menu bar widget.
* Fortunately, we can find it by enumerating the children of the
* top-level window and looking for one we didn't put there
* ourselves.
*/
{
struct find_app_menu_bar_ctx actx, *ctx = &actx;
ctx->area = inst->area;
ctx->menubar = NULL;
gtk_container_foreach(GTK_CONTAINER(inst->window),
find_app_menu_bar, ctx);
if (ctx->menubar) {
GtkRequisition req;
int min_menu_width;
gtk_widget_get_preferred_size(ctx->menubar, NULL, &req);
/*
* This time, the height adjustment is easy (the menu bar
* sits above everything), but we have to take care with
* the _width_ to ensure we keep min_width and base_width
* congruent modulo width_inc.
*/
geom->min_height += req.height;
geom->base_height += req.height;
min_menu_width = req.width;
min_menu_width += geom->width_inc - 1;
min_menu_width -=
((min_menu_width - geom->base_width%geom->width_inc)
% geom->width_inc);
if (geom->min_width < min_menu_width)
geom->min_width = min_menu_width;
}
}
#endif
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
}
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
void set_geom_hints(struct gui_data *inst)
{
GdkGeometry geom;
GTK: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
gint flags = GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE | GDK_HINT_RESIZE_INC;
GTK: split out the computation part from set_geom_hints. This is preparation for dealing with the fact that GTK's geometry- based API routines for setting the window size are being deprecated: we'll no longer be able to specify a width/height in characters and have GTK convert that into a pixel size based on the geometry hints we'd already fed it. So we'll need to do that conversion ourselves, and the easiest approach is to make it easy to recompute the geometry hints on our side whenever we need them.
2016-04-04 13:23:25 +03:00
compute_geom_hints(inst, &geom);
GTK: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
#if GTK_CHECK_VERSION(2,0,0)
if (inst->gotpos)
flags |= GDK_HINT_USER_POS;
#endif
gtk_window_set_geometry_hints(GTK_WINDOW(inst->window),
NULL, &geom, flags);
Implemented Change Settings under Unix. We are gradually getting there. [originally from svn r3092]
2003-04-10 22:00:50 +04:00
}
GTK: stop using geometry-based window sizing functions. gtk_window_resize_to_geometry and gtk_window_set_default_geometry are deprecated as of GTK 3.20, so now we do the geometry -> pixel size conversion on our side.
2016-04-04 13:24:24 +03:00
#if GTK_CHECK_VERSION(2,0,0)
static void compute_whole_window_size(struct gui_data *inst,
int wchars, int hchars,
int *wpix, int *hpix)
{
GdkGeometry geom;
compute_geom_hints(inst, &geom);
if (wpix) *wpix = geom.base_width + wchars * geom.width_inc;
if (hpix) *hpix = geom.base_height + hchars * geom.height_inc;
}
#endif
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 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
}
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
need_size = FALSE;
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)) {
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
show_scrollbar(inst, conf_get_int(newconf, CONF_scrollbar));
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
}
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.
*/
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:"),
Make some static text in GTK dialogs selectable. I've made the licence text, the About box, and the host key dialog into GTK selectable edit controls. (The former because it contains a lot of text; the About box because pasting version numbers into bug reports is obviously useful; the host key because of the fingerprint.)
2015-12-22 15:32:48 +03:00
FALSE, "OK", 'o', +1, 1,
Reorganise setup_fonts_ucs so that in case of error it does nothing and returns its error message as a string, instead of actually printing it on standard error and exiting. Now we can preserve the previous error behaviour when we get a nonexistent font name at startup time, but no longer rudely terminate in mid-session if the user configures a bogus font name in Change Settings. [originally from svn r9745]
2013-01-14 01:59:10 +04:00
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
}
Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size. Each gtkfont back end now provides a routine that will return the name of a similar font to the current one but one notch larger or smaller. For Pango, this is just a matter of incrementing the font size field in a standard way; for X11 server-side fonts, we have to go and do an XListFonts query with a wildcard that requests fonts that vary only in the size fields from the current one, and then iterate over the result looking for the best one. (I expect this will be more useful to Pango scalable-font users than to X11 fonts, but it seemed a shame not to give the X11 side my best shot while I was at it.) Choice of hotkey: I know I'm being inconsistent with gnome-terminal's use of Ctrl-plus and Ctrl-minus. I thought that was because I was already using Ctrl-minus as a more convenient synonym for Ctrl-underscore (which sends the actual control code 0x1F), but now I actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus are quite horrible as a keystroke pair anyway (one has to be typed with shift and one without!), and I feel as if the 'less' and 'greater' signs are more specific anyway, in that they specifically indicate _size_ rather than just 'unspecified numerical value'.
2016-11-13 16:53:42 +03:00
static void change_font_size(struct gui_data *inst, int increment)
{
static const int conf_keys[lenof(inst->fonts)] = {
CONF_font, CONF_boldfont, CONF_widefont, CONF_wideboldfont,
};
FontSpec *oldfonts[lenof(inst->fonts)];
FontSpec *newfonts[lenof(inst->fonts)];
char *errmsg = NULL;
int i;
for (i = 0; i < lenof(newfonts); i++)
oldfonts[i] = newfonts[i] = NULL;
for (i = 0; i < lenof(inst->fonts); i++) {
if (inst->fonts[i]) {
char *newname = unifont_size_increment(inst->fonts[i], increment);
if (!newname)
goto cleanup;
newfonts[i] = fontspec_new(newname);
sfree(newname);
}
}
for (i = 0; i < lenof(newfonts); i++) {
if (newfonts[i]) {
oldfonts[i] = fontspec_copy(
conf_get_fontspec(inst->conf, conf_keys[i]));
conf_set_fontspec(inst->conf, conf_keys[i], newfonts[i]);
}
}
errmsg = setup_fonts_ucs(inst);
if (errmsg)
goto cleanup;
/* Success, so suppress putting everything back */
for (i = 0; i < lenof(newfonts); i++) {
if (oldfonts[i]) {
fontspec_free(oldfonts[i]);
oldfonts[i] = NULL;
}
}
set_geom_hints(inst);
request_resize(inst, conf_get_int(inst->conf, CONF_width),
conf_get_int(inst->conf, CONF_height));
term_invalidate(inst->term);
gtk_widget_queue_draw(inst->area);
cleanup:
for (i = 0; i < lenof(oldfonts); i++) {
if (oldfonts[i]) {
conf_set_fontspec(inst->conf, conf_keys[i], oldfonts[i]);
fontspec_free(oldfonts[i]);
}
if (newfonts[i])
fontspec_free(newfonts[i]);
}
sfree(errmsg);
}
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 21:37:15 +04:00
void dup_session_menuitem(GtkMenuItem *item, gpointer gdata)
{
struct gui_data *inst = (struct gui_data *)gdata;
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-23 00:24:30 +03:00
launch_duplicate_session(inst->conf);
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 21:37:15 +04:00
}
void new_session_menuitem(GtkMenuItem *item, gpointer data)
{
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-23 00:24:30 +03:00
launch_new_session();
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 21:37:15 +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
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)
{
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
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-23 00:24:30 +03:00
launch_saved_session(str);
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 21:37:15 +04:00
}
void saved_session_freedata(GtkMenuItem *item, gpointer data)
{
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 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
}
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-06 00:46:53 +03:00
static void get_monitor_geometry(GtkWidget *widget, GdkRectangle *geometry)
{
#if GTK_CHECK_VERSION(3,4,0)
GdkDisplay *display = gtk_widget_get_display(widget);
GdkWindow *gdkwindow = gtk_widget_get_window(widget);
# if GTK_CHECK_VERSION(3,22,0)
GdkMonitor *monitor;
if (gdkwindow)
monitor = gdk_display_get_monitor_at_window(display, gdkwindow);
else
monitor = gdk_display_get_monitor(display, 0);
gdk_monitor_get_geometry(monitor, geometry);
# else
GdkScreen *screen = gdk_display_get_default_screen(display);
gint monitor_num = gdk_screen_get_monitor_at_window(screen, gdkwindow);
gdk_screen_get_monitor_geometry(screen, monitor_num, geometry);
# endif
#else
geometry->x = geometry->y = 0;
geometry->width = gdk_screen_width();
geometry->height = gdk_screen_height();
#endif
}
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-23 00:24:30 +03:00
struct gui_data *new_session_window(Conf *conf, const char *geometry_string)
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 17:04:18 +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;
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 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;
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-23 00:24:30 +03:00
inst->conf = conf;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
inst->wintitle = inst->icontitle = NULL;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 23:05:56 +03:00
inst->drawtype = DRAWTYPE_DEFAULT;
Support smooth scrolling in GTK3. Touchpad gestures can generate much smoother scrolling events than the discrete increments of mouse wheels. GDK3 supports this by means of a new kind of scroll event, with direction GDK_SCROLL_SMOOTH and a floating-point delta value. Added support for this; so in GTK3 mode, you can now touchpad-scroll at a granularity of one line rather than five, but in mouse tracking mode, scroll events are still grouped into 5-line chunks for purposes of turning them into escape sequences to send to the server.
2015-09-25 17:11:44 +03:00
#if GTK_CHECK_VERSION(3,4,0)
inst->cumulative_scroll = 0.0;
#endif
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 21:37:15 +04:00
GTK: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
#ifndef NOT_X_WINDOWS
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-23 00:24:30 +03:00
if (geometry_string) {
int flags, x, y;
unsigned int w, h;
flags = XParseGeometry(geometry_string, &x, &y, &w, &h);
if (flags & WidthValue)
conf_set_int(conf, CONF_width, w);
if (flags & HeightValue)
conf_set_int(conf, CONF_height, h);
if (flags & (XValue | YValue)) {
inst->xpos = x;
inst->ypos = y;
inst->gotpos = TRUE;
inst->gravity = ((flags & XNegative ? 1 : 0) |
(flags & YNegative ? 2 : 0));
}
Support for New Session, Duplicate Session and the Saved Sessions submenu in Unix PuTTY, and Duplicate Session also in pterm. You do _not_ want to know how this is done. Be warned. [originally from svn r3110]
2003-04-12 21:37:15 +04:00
}
GTK: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
#endif
Having created and used uxsel, it actually turns out to be practically trivial to put all the pieces together and create a working prototype of Unix PuTTY! It's missing a lot of things - notably GUI request boxes for host keys and logfiles and so forth, the Event Log, mid-session reconfiguration, session loading and saving, sensible population of the character sets drop-down list and probably other fiddly little things too - but it will put up a config box and then create a GUI window containing an SSH connection to the host you specified, so it's _basically_ there. Woo! [originally from svn r3020]
2003-03-29 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();
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-06 00:45:04 +03:00
gtk_widget_set_name(GTK_WIDGET(inst->area), "drawing-area");
Implemented a Pango back end. GTK 2 PuTTY can now switch seamlessly back and forth between X fonts and Pango fonts, provided you're willing to type in the names of the former by hand. [originally from svn r7937]
2008-03-22 21:11:17 +03: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)
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);
}
}
Delegate GTK window creation to gtkmain.c. This is a weird thing to have to do, but it is necessary: the OS X PuTTY will need its top-level windows to be instances of a thing called GtkApplicationWindow, rather than plain GtkWindow. Hence, the actual creation of windows needs to be somewhere that isn't centralised between the two kinds of front end.
2016-03-24 01:03:46 +03:00
inst->window = make_gtk_toplevel_window(inst);
Use CSS to set window backgrounds with GTK+ 3 gdk_window_set_background was already deprecated, but with GTK+ 3.22 even gdk_window_set_background_rgba is deprecated, so we need a better approach. The best seems to be to go with the flow and inject a custom CSS style for the appropriate widgets.
2017-03-06 00:45:04 +03:00
gtk_widget_set_name(GTK_WIDGET(inst->window), "top-level");
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
{
const char *winclass = conf_get_str(inst->conf, CONF_winclass);
Replace deprecated gtk_window_set_wmclass with raw Xlib. Calling gtk_widget_realize to enforce the existence of an underlying GdkWindow, followed by gdk_window_ensure_native to enforce an underlying X window in turn, allows me to get hold of an X window id on which I can call the Xlib function for setting WM_CLASS, still before the window is mapped. With this change, plus Colin's preceding patches, the whole code base _actually_ compiles and links against GTK 3.22 without any deprecation warnings. (My claim in commit 8ce237234 that it previously did appears to have been completely wrong - my guess is that I'd forgotten to 'make clean' before testing against 3.22 and so some source files had already been compiled against earlier GTK headers.)
2017-03-08 01:57:42 +03:00
if (*winclass) {
#if GTK_CHECK_VERSION(3,22,0)
#ifndef NOT_X_WINDOWS
GdkWindow *gdkwin;
gtk_widget_realize(GTK_WIDGET(inst->window));
gdkwin = gtk_widget_get_window(GTK_WIDGET(inst->window));
if (gdk_window_ensure_native(gdkwin)) {
Display *disp =
GDK_DISPLAY_XDISPLAY(gdk_window_get_display(gdkwin));
XClassHint *xch = XAllocClassHint();
xch->res_name = (char *)winclass;
xch->res_class = (char *)winclass;
XSetClassHint(disp, GDK_WINDOW_XID(gdkwin), xch);
XFree(xch);
}
#endif
/*
* If we do have NOT_X_WINDOWS set, then we don't have any
* function in GTK 3.22 equivalent to the above. But then,
* surely in that situation the deprecated
* gtk_window_set_wmclass wouldn't have done anything
* meaningful in previous GTKs either.
*/
#else
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
gtk_window_set_wmclass(GTK_WINDOW(inst->window),
winclass, winclass);
Replace deprecated gtk_window_set_wmclass with raw Xlib. Calling gtk_widget_realize to enforce the existence of an underlying GdkWindow, followed by gdk_window_ensure_native to enforce an underlying X window in turn, allows me to get hold of an X window id on which I can call the Xlib function for setting WM_CLASS, still before the window is mapped. With this change, plus Colin's preceding patches, the whole code base _actually_ compiles and links against GTK 3.22 without any deprecation warnings. (My claim in commit 8ce237234 that it previously did appears to have been completely wrong - my guess is that I'd forgotten to 'make clean' before testing against 3.22 and so some source files had already been compiled against earlier GTK headers.)
2017-03-08 01:57:42 +03:00
#endif
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +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
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
Initial support for clipboard on OS X. Rather than trying to get my existing hugely complicated X-style clipboard code to somehow work with the Quartz GTK back end, I've written an entirely new and much simpler alternative clipboard handler usnig the higher-leve GtkClipboard interface. It assumes all clipboard text can be converted to and from UTF-8 sensibly (which isn't a good assumption on all front ends, but on OS X I think it's reasonable), and it talks to GDK_SELECTION_CLIPBOARD rather than PRIMARY, which is the only clipboard OS X has. I had to do a fiddly thing to cope with the fact that each call to gtk_clipboard_set_with_data caused a call to the clipboard clear function left over from the previous set of data, so I had to avoid mistaking that for a clipboard-clear for the _new_ data and immediately deselecting it. I did that by allocating a distinct placeholder object in memory for each instance of the copy operation, so that I can tell whether a clipboard-clear is for the current copy or a previous one. This is only very basic support which demonstrates successful copying and pasting is at least possible. For a sensible OS X implementation we'll need a more believable means of generating a paste UI action (it's quite easy to find a Mac on which neither Shift-Ins nor the third mouse button even exists!). Also, after the trouble I had with the clipboard-clear event, it's a bit annoying to find that it _doesn't_ seem to get called when another application becomes the clipboard owner. That may just be something we have to put up with, if I can't find any reason why it's failing.
2015-09-02 23:37:33 +03:00
init_clipboard(inst);
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
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);
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
show_scrollbar(inst, 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(GTK_WIDGET(inst->hbox));
Account for GtkApplicationWindow menu bar in geometry hints. This is another widget that can appear in the top-level window, in addition to the drawing area and scrollbar we put there ourselves, and hence which needs to be accounted for when figuring out the relationship between the drawing area size in character cells and the full window size in pixels. Finding the menu bar widget itself is a bit of a hassle, but having found it, dealing with it is basically the same as dealing with the scrollbar, only with x and y swapped.
2016-04-04 13:28:34 +03:00
/*
* We must call gtk_widget_realize before setting up the geometry
* hints, so that GtkApplicationWindow will have actually created
* its menu bar (if it's going to) and hence compute_geom_hints
* can find it to take its size into account.
*/
gtk_widget_realize(inst->window);
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
set_geom_hints(inst);
#if GTK_CHECK_VERSION(3,0,0)
GTK: stop using geometry-based window sizing functions. gtk_window_resize_to_geometry and gtk_window_set_default_geometry are deprecated as of GTK 3.20, so now we do the geometry -> pixel size conversion on our side.
2016-04-04 13:24:24 +03:00
{
int wp, hp;
compute_whole_window_size(inst, inst->width, inst->height, &wp, &hp);
gtk_window_set_default_size(GTK_WINDOW(inst->window), wp, hp);
}
Rework window geometry to avoid using geometry_widget. Partly this is because the geometry_widget functionality is going away in a later version of GTK3, so sooner or later we'll need not to be using it anyway. But also, it turns out that GTK 3's geometry calculations have the unfortunate effect of setting the window's base and min heights to values that are not congruent mod height_increment (because the former is the value we gave, but the latter is based on the minimum height of the scrollbar), which confuses at least one window manager (xfwm4) and causes the window to be created one row too small. So I've redone all the geometry computations my own way, based on the knowledge that the only widgets visible in the top-level window are the drawing area and the scrollbar and I know how both of those behave, and taking care to keep base_height and min_height congruent to avoid that xfwm4 bug.
2016-03-29 15:42:54 +03:00
#else
{
int w = inst->font_width * inst->width + 2*inst->window_border;
int h = inst->font_height * inst->height + 2*inst->window_border;
#if GTK_CHECK_VERSION(2,0,0)
gtk_widget_set_size_request(inst->area, w, h);
#else
gtk_drawing_area_size(GTK_DRAWING_AREA(inst->area), w, h);
#endif
}
#endif
Switch to using gtk_window_parse_geometry in GTK 2. On GTK versions where it's available, this is a much nicer way of handling the -geometry command-line option, since not only do we get all the faffing about with gravity for free, it also automatically sets the user-position WM hints.
2015-08-08 20:22:05 +03:00
#if GTK_CHECK_VERSION(2,0,0)
GTK: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
if (inst->gotpos) {
static const GdkGravity gravities[] = {
GDK_GRAVITY_NORTH_WEST,
GDK_GRAVITY_NORTH_EAST,
GDK_GRAVITY_SOUTH_WEST,
GDK_GRAVITY_SOUTH_EAST,
};
int x = inst->xpos, y = inst->ypos;
int wp, hp;
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-06 00:46:53 +03:00
GdkRectangle monitor_geometry;
GTK: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
compute_whole_window_size(inst, inst->width, inst->height, &wp, &hp);
Handle deprecation of gdk_screen_{width,height} GTK+ 3.22 deprecates gdk_screen_{width,height} on the grounds that the "screen" here actually refers to a virtual screen that may span multiple monitors, and applications should generally be considering the width and height of individual monitors. It's not entirely clear to me how this fits with X geometry specifications, but I've gone with trying to get hold of the geometry of the monitor that the window in question is on.
2017-03-06 00:46:53 +03:00
get_monitor_geometry(GTK_WIDGET(inst->window), &monitor_geometry);
if (inst->gravity & 1) x += (monitor_geometry.width - wp);
if (inst->gravity & 2) y += (monitor_geometry.height - hp);
GTK: stop using gtk_window_parse_geometry. This function, which parses the X11-style '-geometry WxH+X+Y' option argument and automatically loads the result into the window, is also being deprecated. Fortunately we already had a fallback option for GTK1 (which didn't have gtk_window_parse_geometry in the first place), calling the Xlib geometry-parsing function and manually loading the results into GTK. The method of loading into GTK is not the same between the two versions, but the basic strategy is still viable. For the sake of maintaining and testing fewer ifdef branches, I've removed the use of gtk_window_parse_geometry _completely_, even in GTK2 which did have it. GTK2 now uses the same strategy that I've switched to for GTK3.
2016-04-04 13:27:01 +03:00
gtk_window_set_gravity(GTK_WINDOW(inst->window),
gravities[inst->gravity & 3]);
gtk_window_move(GTK_WINDOW(inst->window), x, y);
Switch to using gtk_window_parse_geometry in GTK 2. On GTK versions where it's available, this is a much nicer way of handling the -geometry command-line option, since not only do we get all the faffing about with gravity for free, it also automatically sets the user-position WM hints.
2015-08-08 20:22:05 +03:00
}
#else
While writing gtkdlg.c I learned how to specify a window's initial position in GTK, so I can now implement the other half of -geometry which I'd previously believed to be impossible in GTK. It's still not perfect, because GTK apparently provides no way for us to get hold of the X reparent event in order to support negative geometries in a manner which takes account of the WM borders; but for positive position it's at least an improvement on the previous version! [originally from svn r3078]
2003-04-08 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);
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 |
Make scroll events work again in GTK3. Apparently, if you don't specify GDK_SMOOTH_SCROLL_MASK in a widget's event mask, then you don't receive "scroll_event" signals at all, even of the non-smooth variety that was all GTK2 had. Hence, neither mouse scroll wheels nor touchpad scroll gestures seem to generate any response. Adding GDK_SMOOTH_SCROLL_MASK brings the old scroll events back again, so this is at least no worse than GTK2 was. But in GTK3 we _ought_ to be able to do better still, by supporting smooth scrolling from touchpads; this commit doesn't do that.
2015-09-25 16:09:57 +03:00
GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK
#if GTK_CHECK_VERSION(3,4,0)
| GDK_SMOOTH_SCROLL_MASK
#endif
);
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 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();
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
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
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;
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-23 00:24:30 +03:00
return 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
}