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

4413 lines
148 KiB
C
Raw Permalink Normal View History

First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* dialog.c - GTK implementation of the PuTTY configuration box.
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
*/
#include <assert.h>
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
#include <stdarg.h>
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
#include <ctype.h>
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
#include <time.h>
Introduce a config option for building on OS X GTK. Using GTK to run on OS X is going to require several workarounds and behaviour tweaks to be enabled at various points in the code, and it's already getting cumbersome to remember what they all are to put on the command line. Here's a central #define (OSX_GTK) that enables them all in one go, and a configure option (--with-quartz) that sets it. As part of this commit, I've also rearranged the #include order in the GTK source files, so that they include unix.h (which now might be where NOT_X_WINDOWS gets defined) before they test NOT_X_WINDOWS to decide whether to include X11 headers.
2015-08-31 12:05:51 +00:00
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
#include <gtk/gtk.h>
GTK 3 prep: do not include individual GTK/GDK headers. This is the first of several cleanup steps recommended by the GTK 2->3 migration guide. I intend to begin work towards compatibility with GTK 3, but without breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is still useful to _me_ (not least because it permits much easier support of old-style server-side X11 fonts), and I recall hearing a rumour that at least one kind of strange system can only run GTK 1, so for the moment I don't intend to stop supporting either. Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does not include it. In GTK 3 it does, so we don't explicitly reinclude it ourselves. We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But that doesn't say much, because we did already! Apparently gdkkeysyms.h was a special case which that #define didn't forbid.)
2015-08-08 14:06:15 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
#include <gdk/gdkkeysyms.h>
GTK 3 prep: do not include individual GTK/GDK headers. This is the first of several cleanup steps recommended by the GTK 2->3 migration guide. I intend to begin work towards compatibility with GTK 3, but without breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is still useful to _me_ (not least because it permits much easier support of old-style server-side X11 fonts), and I recall hearing a rumour that at least one kind of strange system can only run GTK 1, so for the moment I don't intend to stop supporting either. Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does not include it. In GTK 3 it does, so we don't explicitly reinclude it ourselves. We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But that doesn't say much, because we did already! Apparently gdkkeysyms.h was a special case which that #define didn't forbid.)
2015-08-08 14:06:15 +00:00
#endif
Introduce a config option for building on OS X GTK. Using GTK to run on OS X is going to require several workarounds and behaviour tweaks to be enabled at various points in the code, and it's already getting cumbersome to remember what they all are to put on the command line. Here's a central #define (OSX_GTK) that enables them all in one go, and a configure option (--with-quartz) that sets it. As part of this commit, I've also rearranged the #include order in the GTK source files, so that they include unix.h (which now might be where NOT_X_WINDOWS gets defined) before they test NOT_X_WINDOWS to decide whether to include X11 headers.
2015-08-31 12:05:51 +00:00
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
#define MAY_REFER_TO_GTK_IN_HEADERS
Introduce a config option for building on OS X GTK. Using GTK to run on OS X is going to require several workarounds and behaviour tweaks to be enabled at various points in the code, and it's already getting cumbersome to remember what they all are to put on the command line. Here's a central #define (OSX_GTK) that enables them all in one go, and a configure option (--with-quartz) that sets it. As part of this commit, I've also rearranged the #include order in the GTK source files, so that they include unix.h (which now might be where NOT_X_WINDOWS gets defined) before they test NOT_X_WINDOWS to decide whether to include X11 headers.
2015-08-31 12:05:51 +00:00
#include "putty.h"
#include "gtkcompat.h"
Rename most of the platform source files. This gets rid of all those annoying 'win', 'ux' and 'gtk' prefixes which made filenames annoying to type and to tab-complete. Also, as with my other recent renaming sprees, I've taken the opportunity to expand and clarify some of the names so that they're not such cryptic abbreviations.
2021-04-23 05:19:05 +00:00
#include "columns.h"
#include "unifont.h"
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
#include "gtkmisc.h"
Introduce a config option for building on OS X GTK. Using GTK to run on OS X is going to require several workarounds and behaviour tweaks to be enabled at various points in the code, and it's already getting cumbersome to remember what they all are to put on the command line. Here's a central #define (OSX_GTK) that enables them all in one go, and a configure option (--with-quartz) that sets it. As part of this commit, I've also rearranged the #include order in the GTK source files, so that they include unix.h (which now might be where NOT_X_WINDOWS gets defined) before they test NOT_X_WINDOWS to decide whether to include X11 headers.
2015-08-31 12:05:51 +00:00
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#ifndef NOT_X_WINDOWS
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
#include <gdk/gdkx.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
#include "x11misc.h"
Allow direct use of X11 to be conditionally compiled out. A major aim of introducing GTK 3 support is to permit compiling for non-X11 platforms that GTK 3 supports, so I'm going to need to be able to build as a pure GTK application with no use of X11 internals. Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode in which X server-side bitmap fonts are available. Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's the same compatibility flag that was already used by the unfinished OS X port to disable the X-specific parts of uxpty.c; now it just applies to more source files. (There's no 'configure' option to set this flag at present. I haven't worked out whether we'll need one yet.)
2015-08-08 15:35:19 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
#include "storage.h"
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
#include "dialog.h"
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
#include "tree234.h"
Stop copying the licence text into C source code. Now all the uses of the licence text or the short copyright notice get it from a new header "licence.h", which in turn is built by a Perl script licence.pl invoked by mkfiles.pl, using LICENCE itself as the source. Hence, I can completely remove a whole section from the list of licence locations in CHECKLST.txt :-)
2015-12-22 12:43:31 +00:00
#include "licence.h"
Pass more information to interactive host key check. Now we pass the whole set of fingerprints, and also a displayable format for the full host public key. NFC: this commit doesn't modify any of the host key prompts to _use_ any of the new information. That's coming next.
2021-03-13 10:59:47 +00:00
#include "ssh.h"
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
#if GTK_CHECK_VERSION(2,0,0)
/* Decide which of GtkFileChooserDialog and GtkFileSelection to use */
#define USE_GTK_FILE_CHOOSER_DIALOG
#endif
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
struct Shortcut {
GtkWidget *widget;
struct uctrl *uc;
int action;
};
struct Shortcuts {
struct Shortcut sc[128];
};
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
struct selparam;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl {
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *ctrl;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
GtkWidget *toplevel;
GtkWidget **buttons; int nbuttons; /* for radio buttons */
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
GtkWidget *entry; /* for editbox, filesel, fontsel */
Rename a structure field to avoid clashing with one of the old GTK1 ones. (I'm going to merge the GTK1 list code back in under ifdefs, and I want none of the disputed structure fields to have the same names, so that I'll reliably be told by the compiler if I keep the wrong piece of code outside the ifdef.) [originally from svn r7965]
2008-04-04 10:16:24 +00:00
GtkWidget *button; /* for filesel, fontsel */
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *list; /* for listbox (in GTK1), combobox (<=GTK2.3) */
GtkWidget *menu; /* for optionmenu (==droplist) */
GtkWidget *optmenu; /* also for optionmenu */
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
GtkWidget *combo; /* for combo box (either editable or not) */
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
#if GTK_CHECK_VERSION(2,0,0)
GtkWidget *treeview; /* for listbox (GTK2), droplist+combo (>=2.4) */
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
GtkListStore *listmodel; /* for all types of list box */
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *text; /* for text */
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
GtkWidget *label; /* for dlg_label_change */
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
GtkAdjustment *adj; /* for the scrollbar in a list box */
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
struct selparam *sp; /* which switchable pane of the box we're in */
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
guint textsig;
Patch from John Sullivan: process double-clicks in the session list box on button-up rather than button-down. The effect of this is that if a saved session is already selected in the list box and then you double-click it, it will open rather than beeping annoyingly. [originally from svn r7414]
2007-03-27 18:16:36 +00:00
int nclicks;
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
const char *textvalue; /* temporary, for button-only file selectors */
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
};
struct dlgparam {
tree234 *byctrl, *bywidget;
void *data;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
struct {
unsigned char r, g, b; /* 0-255 */
bool ok;
} coloursel_result;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
/* `flags' are set to indicate when a GTK signal handler is being called
* due to automatic processing and should not flag a user event. */
int flags;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
struct Shortcuts *shortcuts;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
GtkWidget *window, *cancelbutton;
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *currfocus, *lastfocus;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
GtkWidget *currtreeitem, **treeitems;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
int ntreeitems;
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
#else
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
size_t nselparams;
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
struct selparam **selparams;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
struct selparam *curr_panel;
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
struct controlbox *ctrlbox;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
int retval;
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
post_dialog_fn_t after;
void *afterctx;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
};
#define FLAG_UPDATING_COMBO_LIST 1
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
#define FLAG_UPDATING_LISTBOX 2
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
enum { /* values for Shortcut.action */
SHORTCUT_EMPTY, /* no shortcut on this key */
SHORTCUT_TREE, /* focus a tree item */
SHORTCUT_FOCUS, /* focus the supplied widget */
SHORTCUT_UCTRL, /* do something sane with uctrl */
SHORTCUT_UCTRL_UP, /* uctrl is a draglist, move Up */
SHORTCUT_UCTRL_DOWN, /* uctrl is a draglist, move Down */
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
};
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
enum {
TREESTORE_PATH,
TREESTORE_PARAMS,
TREESTORE_NUM
};
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
/*
* Forward references.
*/
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
static gboolean widget_focus(GtkWidget *widget, GdkEventFocus *event,
gpointer data);
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
static void shortcut_add(struct Shortcuts *scs, GtkWidget *labelw,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int chr, int action, void *ptr);
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
static void shortcut_highlight(GtkWidget *label, int chr);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
static gboolean listitem_single_key(GtkWidget *item, GdkEventKey *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
static gboolean listitem_multi_key(GtkWidget *item, GdkEventKey *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
static gboolean listitem_button_press(GtkWidget *item, GdkEventButton *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
static gboolean listitem_button_release(GtkWidget *item, GdkEventButton *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
#if !GTK_CHECK_VERSION(2,4,0)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
static void menuitem_activate(GtkMenuItem *item, gpointer data);
#endif
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#if GTK_CHECK_VERSION(3,0,0)
static void colourchoose_response(GtkDialog *dialog,
gint response_id, gpointer data);
#else
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static void coloursel_ok(GtkButton *button, gpointer data);
static void coloursel_cancel(GtkButton *button, gpointer data);
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#endif
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
static void dlgparam_destroy(GtkWidget *widget, gpointer data);
Add missing 'static' on file-internal declarations. sk_startup and sk_nextaddr are entirely internal to winnet.c; nearly all of import.c and minibidi.c's internal routines should have been static and weren't; {read,write}_utf8 are internal to charset/utf8.c (and didn't even need separate declarations at all); do_sftp_cleanup is internal to psftp.c, and get_listitemheight to gtkdlg.c. While I was editing those prototypes anyway, I've also added missing 'const' to the 'char *' passphrase parameters in import,c.
2018-11-03 08:25:28 +00:00
static int get_listitemheight(GtkWidget *widget);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static int uctrl_cmp_byctrl(void *av, void *bv)
{
struct uctrl *a = (struct uctrl *)av;
struct uctrl *b = (struct uctrl *)bv;
if (a->ctrl < b->ctrl)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return -1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
else if (a->ctrl > b->ctrl)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return +1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
return 0;
}
static int uctrl_cmp_byctrl_find(void *av, void *bv)
{
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *a = (dlgcontrol *)av;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *b = (struct uctrl *)bv;
if (a < b->ctrl)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return -1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
else if (a > b->ctrl)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return +1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
return 0;
}
static int uctrl_cmp_bywidget(void *av, void *bv)
{
struct uctrl *a = (struct uctrl *)av;
struct uctrl *b = (struct uctrl *)bv;
if (a->toplevel < b->toplevel)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return -1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
else if (a->toplevel > b->toplevel)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return +1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
return 0;
}
static int uctrl_cmp_bywidget_find(void *av, void *bv)
{
GtkWidget *a = (GtkWidget *)av;
struct uctrl *b = (struct uctrl *)bv;
if (a < b->toplevel)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return -1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
else if (a > b->toplevel)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return +1;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
return 0;
}
static void dlg_init(struct dlgparam *dp)
{
dp->byctrl = newtree234(uctrl_cmp_byctrl);
dp->bywidget = newtree234(uctrl_cmp_bywidget);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
dp->coloursel_result.ok = false;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
dp->window = dp->cancelbutton = NULL;
#if !GTK_CHECK_VERSION(2,0,0)
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
dp->treeitems = NULL;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
dp->currtreeitem = NULL;
#endif
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
dp->curr_panel = NULL;
Various uninitialised-variable accesses picked up by valgrind. [originally from svn r3723]
2004-01-17 14:25:36 +00:00
dp->flags = 0;
dp->currfocus = NULL;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
static void dlg_cleanup(struct dlgparam *dp)
{
struct uctrl *uc;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
freetree234(dp->byctrl); /* doesn't free the uctrls inside */
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
dp->byctrl = NULL;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
while ( (uc = index234(dp->bywidget, 0)) != NULL) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
del234(dp->bywidget, uc);
sfree(uc->buttons);
sfree(uc);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
freetree234(dp->bywidget);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
dp->bywidget = NULL;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
sfree(dp->treeitems);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
static void dlg_add_uctrl(struct dlgparam *dp, struct uctrl *uc)
{
add234(dp->byctrl, uc);
add234(dp->bywidget, uc);
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
static struct uctrl *dlg_find_byctrl(struct dlgparam *dp, dlgcontrol *ctrl)
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
{
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
if (!dp->byctrl)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
return find234(dp->byctrl, ctrl, uctrl_cmp_byctrl_find);
}
static struct uctrl *dlg_find_bywidget(struct dlgparam *dp, GtkWidget *w)
{
struct uctrl *ret = NULL;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
if (!dp->bywidget)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
do {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret = find234(dp->bywidget, w, uctrl_cmp_bywidget_find);
if (ret)
return ret;
w = gtk_widget_get_parent(w);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
} while (w);
return ret;
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *dlg_last_focused(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
if (dp->currfocus != ctrl)
return dp->currfocus;
else
return dp->lastfocus;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_radiobutton_set(dlgcontrol *ctrl, dlgparam *dp, int which)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_RADIO);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
assert(uc->buttons != NULL);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(uc->buttons[which]), true);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
int dlg_radiobutton_get(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
int i;
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_RADIO);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
assert(uc->buttons != NULL);
for (i = 0; i < uc->nbuttons; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (gtk_toggle_button_get_active(GTK_TOGGLE_BUTTON(uc->buttons[i])))
return i;
return 0; /* got to return something */
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_checkbox_set(dlgcontrol *ctrl, dlgparam *dp, bool checked)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_CHECKBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(uc->toplevel), checked);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
bool dlg_checkbox_get(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_CHECKBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
return gtk_toggle_button_get_active(GTK_TOGGLE_BUTTON(uc->toplevel));
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Add UTF-8 versions of dlg_editbox_{get,set}. There's no difficulty with implementing these, on either platform. Windows has native Unicode support for its edit boxes: we can set and retrieve the text as a wide-character string, and then converting it to and from UTF-8 is easy. And GTK has specified its edit boxes as being UTF-8 all along, no matter what the system locale.
2024-09-23 13:20:44 +00:00
void dlg_editbox_set_utf8(dlgcontrol *ctrl, dlgparam *dp, char const *text)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
GtkWidget *entry;
char *tmpstring;
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if GTK_CHECK_VERSION(2,4,0)
if (uc->combo)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
entry = gtk_bin_get_child(GTK_BIN(uc->combo));
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
else
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
entry = uc->entry;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
assert(entry != NULL);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
A nasty GTK signal cascade was causing any edit box whose contents was modified on session load to be blanked. More details in the comment in dlg_editbox_set(). [originally from svn r7161]
2007-01-25 19:47:36 +00:00
/*
* GTK 2 implements gtk_entry_set_text by means of two separate
* operations: first delete the previous text leaving the empty
* string, then insert the new text. This causes two calls to
* the "changed" signal.
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
*
A nasty GTK signal cascade was causing any edit box whose contents was modified on session load to be blanked. More details in the comment in dlg_editbox_set(). [originally from svn r7161]
2007-01-25 19:47:36 +00:00
* The first call to "changed", if allowed to proceed normally,
* will cause an EVENT_VALCHANGE event on the edit box, causing
* a call to dlg_editbox_get() which will read the empty string
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
* out of the GtkEntry - and promptly write it straight into the
* Conf structure, which is precisely where our `text' pointer
* is probably pointing, so the second editing operation will
* insert that instead of the string we originally asked for.
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
*
* Hence, we must take our own copy of the text before we do
* this.
A nasty GTK signal cascade was causing any edit box whose contents was modified on session load to be blanked. More details in the comment in dlg_editbox_set(). [originally from svn r7161]
2007-01-25 19:47:36 +00:00
*/
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
tmpstring = dupstr(text);
gtk_entry_set_text(GTK_ENTRY(entry), tmpstring);
sfree(tmpstring);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Add UTF-8 versions of dlg_editbox_{get,set}. There's no difficulty with implementing these, on either platform. Windows has native Unicode support for its edit boxes: we can set and retrieve the text as a wide-character string, and then converting it to and from UTF-8 is easy. And GTK has specified its edit boxes as being UTF-8 all along, no matter what the system locale.
2024-09-23 13:20:44 +00:00
void dlg_editbox_set(dlgcontrol *ctrl, dlgparam *dp, char const *text)
{
/* GTK specifies that its edit boxes are always in UTF-8 anyway,
* so legacy behaviour is to use those strings unmodified */
dlg_editbox_set_utf8(ctrl, dp, text);
}
char *dlg_editbox_get_utf8(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if GTK_CHECK_VERSION(2,4,0)
if (uc->combo) {
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
return dupstr(gtk_entry_get_text(
GTK_ENTRY(gtk_bin_get_child(GTK_BIN(uc->combo)))));
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
if (uc->entry) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return dupstr(gtk_entry_get_text(GTK_ENTRY(uc->entry)));
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in editbox_get");
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Add UTF-8 versions of dlg_editbox_{get,set}. There's no difficulty with implementing these, on either platform. Windows has native Unicode support for its edit boxes: we can set and retrieve the text as a wide-character string, and then converting it to and from UTF-8 is easy. And GTK has specified its edit boxes as being UTF-8 all along, no matter what the system locale.
2024-09-23 13:20:44 +00:00
char *dlg_editbox_get(dlgcontrol *ctrl, dlgparam *dp)
{
/* GTK specifies that its edit boxes are always in UTF-8 anyway,
* so legacy behaviour is to use those strings unmodified */
return dlg_editbox_get_utf8(ctrl, dp);
}
New function dlg_editbox_select_range. This manipulates the selection inside an edit box, to select a specific range of characters in the contained text. The idea is that you can use it as a means of error highlighting, if the user has entered something invalid in that edit box and you want to draw their attention to the specific location of the part you're unhappy with.
2022-06-25 12:00:06 +00:00
void dlg_editbox_select_range(dlgcontrol *ctrl, dlgparam *dp,
size_t start, size_t len)
{
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
assert(uc->ctrl->type == CTRL_EDITBOX);
GtkWidget *entry = NULL;
#if GTK_CHECK_VERSION(2,4,0)
if (uc->combo)
entry = gtk_bin_get_child(GTK_BIN(uc->combo));
#endif
if (uc->entry)
entry = uc->entry;
assert(entry && "we should have a GtkEntry one way or another");
gtk_editable_select_region(GTK_EDITABLE(entry), start, start + len);
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
static void container_remove_and_destroy(GtkWidget *w, gpointer data)
{
GtkContainer *cont = GTK_CONTAINER(data);
/* gtk_container_remove will unref the widget for us; we need not. */
gtk_container_remove(cont, w);
}
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/* The `listbox' functions can also apply to combo boxes. */
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_listbox_clear(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (uc->menu) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_container_foreach(GTK_CONTAINER(uc->menu),
container_remove_and_destroy,
GTK_CONTAINER(uc->menu));
return;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
if (uc->list) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_list_clear_items(GTK_LIST(uc->list), 0, -1);
return;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
#endif
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if GTK_CHECK_VERSION(2,0,0)
if (uc->listmodel) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_list_store_clear(uc->listmodel);
return;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in listbox_clear");
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_listbox_del(dlgcontrol *ctrl, dlgparam *dp, int index)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (uc->menu) {
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_container_remove(
GTK_CONTAINER(uc->menu),
g_list_nth_data(GTK_MENU_SHELL(uc->menu)->children, index));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
if (uc->list) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_list_clear_items(GTK_LIST(uc->list), index, index+1);
return;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
#if GTK_CHECK_VERSION(2,0,0)
if (uc->listmodel) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreePath *path;
GtkTreeIter iter;
assert(uc->listmodel != NULL);
path = gtk_tree_path_new_from_indices(index, -1);
gtk_tree_model_get_iter(GTK_TREE_MODEL(uc->listmodel), &iter, path);
gtk_list_store_remove(uc->listmodel, &iter);
gtk_tree_path_free(path);
return;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in listbox_del");
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_listbox_add(dlgcontrol *ctrl, dlgparam *dp, char const *text)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
dlg_listbox_addwithid(ctrl, dp, text, 0);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
/*
* Each listbox entry may have a numeric id associated with it.
* Note that some front ends only permit a string to be stored at
* each position, which means that _if_ you put two identical
* strings in any listbox then you MUST not assign them different
* IDs and expect to get meaningful results back.
*/
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_listbox_addwithid(dlgcontrol *ctrl, dlgparam *dp,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char const *text, int id)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
/*
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
* This routine is long and complicated in both GTK 1 and 2,
* and completely different. Sigh.
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
*/
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
dp->flags |= FLAG_UPDATING_COMBO_LIST;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (uc->menu) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* List item in a drop-down (but non-combo) list. Tabs are
* ignored; we just provide a standard menu item with the
* text.
*/
GtkWidget *menuitem = gtk_menu_item_new_with_label(text);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_container_add(GTK_CONTAINER(uc->menu), menuitem);
gtk_widget_show(menuitem);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set_data(G_OBJECT(menuitem), "user-data",
GINT_TO_POINTER(id));
g_signal_connect(G_OBJECT(menuitem), "activate",
G_CALLBACK(menuitem_activate), dp);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
goto done;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
if (uc->list && uc->entry) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* List item in a combo-box list, which means the sensible
* thing to do is make it a perfectly normal label. Hence
* tabs are disregarded.
*/
GtkWidget *listitem = gtk_list_item_new_with_label(text);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_container_add(GTK_CONTAINER(uc->list), listitem);
gtk_widget_show(listitem);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set_data(G_OBJECT(listitem), "user-data",
GINT_TO_POINTER(id));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
goto done;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#endif
#if !GTK_CHECK_VERSION(2,0,0)
if (uc->list) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* List item in a non-combo-box list box. We make all of
* these Columns containing GtkLabels. This allows us to do
* the nasty force_left hack irrespective of whether there
* are tabs in the thing.
*/
GtkWidget *listitem = gtk_list_item_new();
GtkWidget *cols = columns_new(10);
gint *percents;
int i, ncols;
/* Count the tabs in the text, and hence determine # of columns. */
ncols = 1;
for (i = 0; text[i]; i++)
if (text[i] == '\t')
ncols++;
assert(ncols <=
(uc->ctrl->listbox.ncols ? uc->ctrl->listbox.ncols : 1));
percents = snewn(ncols, gint);
percents[ncols-1] = 100;
for (i = 0; i < ncols-1; i++) {
percents[i] = uc->ctrl->listbox.percentages[i];
percents[ncols-1] -= percents[i];
}
columns_set_cols(COLUMNS(cols), ncols, percents);
sfree(percents);
for (i = 0; i < ncols; i++) {
int len = strcspn(text, "\t");
char *dup = dupprintf("%.*s", len, text);
GtkWidget *label;
text += len;
if (*text) text++;
label = gtk_label_new(dup);
sfree(dup);
columns_add(COLUMNS(cols), label, i, 1);
columns_force_left_align(COLUMNS(cols), label);
gtk_widget_show(label);
}
gtk_container_add(GTK_CONTAINER(listitem), cols);
gtk_widget_show(cols);
gtk_container_add(GTK_CONTAINER(uc->list), listitem);
gtk_widget_show(listitem);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (ctrl->listbox.multisel) {
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(listitem), "key_press_event",
G_CALLBACK(listitem_multi_key), uc->adj);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
} else {
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(listitem), "key_press_event",
G_CALLBACK(listitem_single_key), uc->adj);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(listitem), "focus_in_event",
G_CALLBACK(widget_focus), dp);
g_signal_connect(G_OBJECT(listitem), "button_press_event",
G_CALLBACK(listitem_button_press), dp);
g_signal_connect(G_OBJECT(listitem), "button_release_event",
G_CALLBACK(listitem_button_release), dp);
g_object_set_data(G_OBJECT(listitem), "user-data",
GINT_TO_POINTER(id));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
goto done;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
if (uc->listmodel) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreeIter iter;
int i, cols;
dp->flags |= FLAG_UPDATING_LISTBOX;/* inhibit drag-list update */
gtk_list_store_append(uc->listmodel, &iter);
dp->flags &= ~FLAG_UPDATING_LISTBOX;
gtk_list_store_set(uc->listmodel, &iter, 0, id, -1);
/*
* Now go through text and divide it into columns at the tabs,
* as necessary.
*/
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
cols = (uc->ctrl->type == CTRL_LISTBOX ? ctrl->listbox.ncols : 1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cols = cols ? cols : 1;
for (i = 0; i < cols; i++) {
int collen = strcspn(text, "\t");
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
char *tmpstr = mkstr(make_ptrlen(text, collen));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_list_store_set(uc->listmodel, &iter, i+1, tmpstr, -1);
sfree(tmpstr);
text += collen;
if (*text) text++;
}
goto done;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in listbox_addwithid");
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
done:
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
dp->flags &= ~FLAG_UPDATING_COMBO_LIST;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
int dlg_listbox_getid(dlgcontrol *ctrl, dlgparam *dp, int index)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
if (uc->menu || uc->list) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GList *children;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
GObject *item;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
children = gtk_container_children(GTK_CONTAINER(uc->menu ? uc->menu :
uc->list));
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
item = G_OBJECT(g_list_nth_data(children, index));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
g_list_free(children);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
return GPOINTER_TO_INT(g_object_get_data(G_OBJECT(item), "user-data"));
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
#if GTK_CHECK_VERSION(2,0,0)
if (uc->listmodel) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreePath *path;
GtkTreeIter iter;
int ret;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
path = gtk_tree_path_new_from_indices(index, -1);
gtk_tree_model_get_iter(GTK_TREE_MODEL(uc->listmodel), &iter, path);
gtk_tree_model_get(GTK_TREE_MODEL(uc->listmodel), &iter, 0, &ret, -1);
gtk_tree_path_free(path);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return ret;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in listbox_getid");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return -1; /* placate dataflow analysis */
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
/* dlg_listbox_index returns <0 if no single element is selected. */
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
int dlg_listbox_index(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
if (uc->menu || uc->list) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GList *children;
GtkWidget *item, *activeitem;
int i;
int selected = -1;
if (uc->menu)
activeitem = gtk_menu_get_active(GTK_MENU(uc->menu));
else
activeitem = NULL; /* unnecessarily placate gcc */
children = gtk_container_children(GTK_CONTAINER(uc->menu ? uc->menu :
uc->list));
for (i = 0; children!=NULL && (item = GTK_WIDGET(children->data))!=NULL;
i++, children = children->next) {
if (uc->menu ? activeitem == item :
GTK_WIDGET_STATE(item) == GTK_STATE_SELECTED) {
if (selected == -1)
selected = i;
else
selected = -2;
}
}
g_list_free(children);
return selected < 0 ? -1 : selected;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
#else
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
if (uc->combo) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* This API function already does the right thing in the
* case of no current selection.
*/
return gtk_combo_box_get_active(GTK_COMBO_BOX(uc->combo));
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#endif
#if GTK_CHECK_VERSION(2,0,0)
if (uc->treeview) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreeSelection *treesel;
GtkTreePath *path;
GtkTreeModel *model;
GList *sellist;
gint *indices;
int ret;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(uc->treeview != NULL);
treesel = gtk_tree_view_get_selection(GTK_TREE_VIEW(uc->treeview));
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (gtk_tree_selection_count_selected_rows(treesel) != 1)
return -1;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sellist = gtk_tree_selection_get_selected_rows(treesel, &model);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(sellist && sellist->data);
path = sellist->data;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (gtk_tree_path_get_depth(path) != 1) {
ret = -1;
} else {
indices = gtk_tree_path_get_indices(path);
if (!indices) {
ret = -1;
} else {
ret = indices[0];
}
}
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
g_list_foreach(sellist, (GFunc)gtk_tree_path_free, NULL);
g_list_free(sellist);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return ret;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in listbox_index");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return -1; /* placate dataflow analysis */
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
bool dlg_listbox_issel(dlgcontrol *ctrl, dlgparam *dp, int index)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
if (uc->menu || uc->list) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GList *children;
GtkWidget *item, *activeitem;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(uc->menu != NULL || uc->list != NULL);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
children = gtk_container_children(GTK_CONTAINER(uc->menu ? uc->menu :
uc->list));
item = GTK_WIDGET(g_list_nth_data(children, index));
g_list_free(children);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (uc->menu) {
activeitem = gtk_menu_get_active(GTK_MENU(uc->menu));
return item == activeitem;
} else {
return GTK_WIDGET_STATE(item) == GTK_STATE_SELECTED;
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
#else
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
if (uc->combo) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* This API function already does the right thing in the
* case of no current selection.
*/
return gtk_combo_box_get_active(GTK_COMBO_BOX(uc->combo)) == index;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#endif
#if GTK_CHECK_VERSION(2,0,0)
if (uc->treeview) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreeSelection *treesel;
GtkTreePath *path;
bool ret;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(uc->treeview != NULL);
treesel = gtk_tree_view_get_selection(GTK_TREE_VIEW(uc->treeview));
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
path = gtk_tree_path_new_from_indices(index, -1);
ret = gtk_tree_selection_path_is_selected(treesel, path);
gtk_tree_path_free(path);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return ret;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in listbox_issel");
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false; /* placate dataflow analysis */
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_listbox_select(dlgcontrol *ctrl, dlgparam *dp, int index)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_EDITBOX ||
uc->ctrl->type == CTRL_LISTBOX);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (uc->optmenu) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_option_menu_set_history(GTK_OPTION_MENU(uc->optmenu), index);
return;
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
if (uc->list) {
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
int nitems;
GList *items;
gdouble newtop, newbot;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_list_select_item(GTK_LIST(uc->list), index);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
/*
* Scroll the list box if necessary to ensure the newly
* selected item is visible.
*/
items = gtk_container_children(GTK_CONTAINER(uc->list));
nitems = g_list_length(items);
if (nitems > 0) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool modified = false;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
g_list_free(items);
newtop = uc->adj->lower +
(uc->adj->upper - uc->adj->lower) * index / nitems;
newbot = uc->adj->lower +
(uc->adj->upper - uc->adj->lower) * (index+1) / nitems;
if (uc->adj->value > newtop) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
modified = true;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
uc->adj->value = newtop;
} else if (uc->adj->value < newbot - uc->adj->page_size) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
modified = true;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
uc->adj->value = newbot - uc->adj->page_size;
}
if (modified)
gtk_adjustment_value_changed(uc->adj);
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
#else
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
if (uc->combo) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_combo_box_set_active(GTK_COMBO_BOX(uc->combo), index);
return;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#endif
#if GTK_CHECK_VERSION(2,0,0)
if (uc->treeview) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreeSelection *treesel;
GtkTreePath *path;
dlg_listbox_select() now scrolls the list box to ensure that the item it's just selected is visible. [originally from svn r6338]
2005-09-21 17:09:07 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
treesel = gtk_tree_view_get_selection(GTK_TREE_VIEW(uc->treeview));
dlg_listbox_select() now scrolls the list box to ensure that the item it's just selected is visible. [originally from svn r6338]
2005-09-21 17:09:07 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
path = gtk_tree_path_new_from_indices(index, -1);
gtk_tree_selection_select_path(treesel, path);
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(uc->treeview),
path, NULL, false, 0.0, 0.0);
gtk_tree_path_free(path);
return;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in listbox_select");
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_text_set(dlgcontrol *ctrl, dlgparam *dp, char const *text)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_TEXT);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
assert(uc->text != NULL);
gtk_label_set_text(GTK_LABEL(uc->text), text);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_label_change(dlgcontrol *ctrl, dlgparam *dp, char const *text)
Support for Windows PuTTY connecting straight to a local serial port in place of making a network connection. This has involved a couple of minor infrastructure changes: - New dlg_label_change() function in the dialog.h interface, which alters the label on a control. Only used, at present, to switch the Host Name and Port boxes into Serial Line and Speed, which means that any platform not implementing serial connections (i.e. currently all but Windows) does not need to actually do anything in this function. Yet. - New small piece of infrastructure: cfg_launchable() determines whether a Config structure describes a session ready to be launched. This was previously determined by seeing if it had a non-empty host name, but it has to check the serial line as well so there's a centralised function for it. I haven't gone through all front ends and arranged for this function to be used everywhere it needs to be; so far I've only checked Windows. - Similarly, cfg_dest() returns the destination of a connection (host name or serial line) in a text format suitable for putting into messages such as `Unable to connect to %s'. [originally from svn r6815]
2006-08-28 10:35:12 +00:00
{
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
switch (uc->ctrl->type) {
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
case CTRL_BUTTON:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_label_set_text(GTK_LABEL(uc->toplevel), text);
shortcut_highlight(uc->toplevel, ctrl->button.shortcut);
break;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
case CTRL_CHECKBOX:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_label_set_text(GTK_LABEL(uc->toplevel), text);
shortcut_highlight(uc->toplevel, ctrl->checkbox.shortcut);
break;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
case CTRL_RADIO:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_label_set_text(GTK_LABEL(uc->label), text);
shortcut_highlight(uc->label, ctrl->radio.shortcut);
break;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
case CTRL_EDITBOX:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_label_set_text(GTK_LABEL(uc->label), text);
shortcut_highlight(uc->label, ctrl->editbox.shortcut);
break;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
case CTRL_FILESELECT:
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
if (uc->label) {
gtk_label_set_text(GTK_LABEL(uc->label), text);
shortcut_highlight(uc->label, ctrl->fileselect.shortcut);
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
case CTRL_FONTSELECT:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_label_set_text(GTK_LABEL(uc->label), text);
shortcut_highlight(uc->label, ctrl->fontselect.shortcut);
break;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
case CTRL_LISTBOX:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_label_set_text(GTK_LABEL(uc->label), text);
shortcut_highlight(uc->label, ctrl->listbox.shortcut);
break;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
default:
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in label_change");
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
}
Support for Windows PuTTY connecting straight to a local serial port in place of making a network connection. This has involved a couple of minor infrastructure changes: - New dlg_label_change() function in the dialog.h interface, which alters the label on a control. Only used, at present, to switch the Host Name and Port boxes into Serial Line and Speed, which means that any platform not implementing serial connections (i.e. currently all but Windows) does not need to actually do anything in this function. Yet. - New small piece of infrastructure: cfg_launchable() determines whether a Config structure describes a session ready to be launched. This was previously determined by seeing if it had a non-empty host name, but it has to check the serial line as well so there's a centralised function for it. I haven't gone through all front ends and arranged for this function to be used everywhere it needs to be; so far I've only checked Windows. - Similarly, cfg_dest() returns the destination of a connection (host name or serial line) in a text format suitable for putting into messages such as `Unable to connect to %s'. [originally from svn r6815]
2006-08-28 10:35:12 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_filesel_set(dlgcontrol *ctrl, dlgparam *dp, Filename *fn)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Add code in dlg_filesel_set and dlg_fontsel_set which makes them duplicate the strings they pass to gtk_entry_set_text. I was already doing that in dlg_editbox_set, but forgot to add the same code when I revamped FontSpec and Filename to contain dynamically allocated strings (r9314 and r9316 respectively). This fixes a bug where, on some versions of GTK (but apparently not up-to-date versions), loading a saved session causes gibberish to appear in file-selector edit boxes accompanied by a valgrind error. [originally from svn r9456] [r9314 == 9c75fe9a3fa5e6b709f1c210795d1140ca1be2e8] [r9316 == 62cbc7dc0b33808dc8794c59f60971fbba97894b]
2012-04-13 18:02:30 +00:00
/* We must copy fn->path before passing it to gtk_entry_set_text.
* See comment in dlg_editbox_set() for the reasons. */
char *duppath = dupstr(fn->path);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_FILESELECT);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
assert(uc->entry != NULL);
Add code in dlg_filesel_set and dlg_fontsel_set which makes them duplicate the strings they pass to gtk_entry_set_text. I was already doing that in dlg_editbox_set, but forgot to add the same code when I revamped FontSpec and Filename to contain dynamically allocated strings (r9314 and r9316 respectively). This fixes a bug where, on some versions of GTK (but apparently not up-to-date versions), loading a saved session causes gibberish to appear in file-selector edit boxes accompanied by a valgrind error. [originally from svn r9456] [r9314 == 9c75fe9a3fa5e6b709f1c210795d1140ca1be2e8] [r9316 == 62cbc7dc0b33808dc8794c59f60971fbba97894b]
2012-04-13 18:02:30 +00:00
gtk_entry_set_text(GTK_ENTRY(uc->entry), duppath);
sfree(duppath);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
Filename *dlg_filesel_get(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_FILESELECT);
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
if (!uc->entry) {
assert(uc->textvalue);
return filename_from_str(uc->textvalue);
} else {
return filename_from_str(gtk_entry_get_text(GTK_ENTRY(uc->entry)));
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_fontsel_set(dlgcontrol *ctrl, dlgparam *dp, FontSpec *fs)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Add code in dlg_filesel_set and dlg_fontsel_set which makes them duplicate the strings they pass to gtk_entry_set_text. I was already doing that in dlg_editbox_set, but forgot to add the same code when I revamped FontSpec and Filename to contain dynamically allocated strings (r9314 and r9316 respectively). This fixes a bug where, on some versions of GTK (but apparently not up-to-date versions), loading a saved session causes gibberish to appear in file-selector edit boxes accompanied by a valgrind error. [originally from svn r9456] [r9314 == 9c75fe9a3fa5e6b709f1c210795d1140ca1be2e8] [r9316 == 62cbc7dc0b33808dc8794c59f60971fbba97894b]
2012-04-13 18:02:30 +00:00
/* We must copy fs->name before passing it to gtk_entry_set_text.
* See comment in dlg_editbox_set() for the reasons. */
char *dupname = dupstr(fs->name);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_FONTSELECT);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
assert(uc->entry != NULL);
Add code in dlg_filesel_set and dlg_fontsel_set which makes them duplicate the strings they pass to gtk_entry_set_text. I was already doing that in dlg_editbox_set, but forgot to add the same code when I revamped FontSpec and Filename to contain dynamically allocated strings (r9314 and r9316 respectively). This fixes a bug where, on some versions of GTK (but apparently not up-to-date versions), loading a saved session causes gibberish to appear in file-selector edit boxes accompanied by a valgrind error. [originally from svn r9456] [r9314 == 9c75fe9a3fa5e6b709f1c210795d1140ca1be2e8] [r9316 == 62cbc7dc0b33808dc8794c59f60971fbba97894b]
2012-04-13 18:02:30 +00:00
gtk_entry_set_text(GTK_ENTRY(uc->entry), dupname);
sfree(dupname);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
FontSpec *dlg_fontsel_get(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
assert(uc->ctrl->type == CTRL_FONTSELECT);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
assert(uc->entry != NULL);
Change the semantics of 'FontSpec' so that it's a dynamically allocated type. The main reason for this is to stop it from taking up a fixed large amount of space in every 'struct value' subunion in conf.c, although that makes little difference so far because Filename is still doing the same thing (and is therefore next on my list). However, the removal of its arbitrary length limit is not to be sneezed at. [originally from svn r9314]
2011-10-01 17:38:59 +00:00
return fontspec_new(gtk_entry_get_text(GTK_ENTRY(uc->entry)));
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
/*
* Bracketing a large set of updates in these two functions will
* cause the front end (if possible) to delay updating the screen
* until it's all complete, thus avoiding flicker.
*/
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_update_start(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
/*
* Apparently we can't do this at all in GTK. GtkCList supports
* freeze and thaw, but not GtkList. Bah.
*/
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_update_done(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
/*
* Apparently we can't do this at all in GTK. GtkCList supports
* freeze and thaw, but not GtkList. Bah.
*/
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_set_focus(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
switch (ctrl->type) {
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
case CTRL_CHECKBOX:
case CTRL_BUTTON:
/* Check boxes and buttons get the focus _and_ get toggled. */
gtk_widget_grab_focus(uc->toplevel);
break;
case CTRL_FILESELECT:
case CTRL_FONTSELECT:
case CTRL_EDITBOX:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (uc->entry) {
/* Anything containing an edit box gets that focused. */
gtk_widget_grab_focus(uc->entry);
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if GTK_CHECK_VERSION(2,4,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
else if (uc->combo) {
/* Failing that, there'll be a combo box. */
gtk_widget_grab_focus(uc->combo);
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
break;
case CTRL_RADIO:
/*
* Radio buttons: we find the currently selected button and
* focus it.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
for (int i = 0; i < ctrl->radio.nbuttons; i++)
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
if (gtk_toggle_button_get_active(
GTK_TOGGLE_BUTTON(uc->buttons[i]))) {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
gtk_widget_grab_focus(uc->buttons[i]);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
break;
case CTRL_LISTBOX:
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (uc->optmenu) {
gtk_widget_grab_focus(uc->optmenu);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (uc->combo) {
gtk_widget_grab_focus(uc->combo);
break;
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
#if !GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (uc->list) {
/*
* For GTK-1 style list boxes, we tell it to focus one
* of its children, which appears to do the Right
* Thing.
*/
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
gtk_container_focus(GTK_CONTAINER(uc->list), GTK_DIR_TAB_FORWARD);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (uc->treeview) {
gtk_widget_grab_focus(uc->treeview);
break;
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad control type in set_focus");
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
/*
* During event processing, you might well want to give an error
* indication to the user. dlg_beep() is a quick and easy generic
* error; dlg_error() puts up a message-box or equivalent.
*/
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
void dlg_beep(dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Use gdk_display_beep() in place of obsolete gdk_beep(). Except in GTK1 (which doesn't have the former), via a gtkcompat.h workaround. Up-to-date GTK3 has deprecated gdk_beep(), causing build failures due to the default -Werror setting.
2018-03-03 18:20:04 +00:00
gdk_display_beep(gdk_display_get_default());
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
static void set_transient_window_pos(GtkWidget *parent, GtkWidget *child)
{
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
gint x, y, w, h, dx, dy;
GtkRequisition req;
gtk_window_set_position(GTK_WINDOW(child), GTK_WIN_POS_NONE);
gtk_widget_size_request(GTK_WIDGET(child), &req);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
gdk_window_get_origin(gtk_widget_get_window(GTK_WIDGET(parent)), &x, &y);
gdk_window_get_size(gtk_widget_get_window(GTK_WIDGET(parent)), &w, &h);
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
/*
* One corner of the transient will be offset inwards, by 1/4
* of the parent window's size, from the corresponding corner
* of the parent window. The corner will be chosen so as to
* place the transient closer to the centre of the screen; this
* should avoid transients going off the edge of the screen on
* a regular basis.
*/
if (x + w/2 < gdk_screen_width() / 2)
dx = x + w/4; /* work from left edges */
else
dx = x + 3*w/4 - req.width; /* work from right edges */
if (y + h/2 < gdk_screen_height() / 2)
dy = y + h/4; /* work from top edges */
else
dy = y + 3*h/4 - req.height; /* work from bottom edges */
gtk_widget_set_uposition(GTK_WIDGET(child), dx, dy);
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
#endif
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
}
Make the GTK font setup error box non-modal. That was the last (in fact, the only) call to the modal version of message_box() outside gtkdlg.c, so I can remove it from the header file.
2017-11-26 17:07:47 +00:00
void trivial_post_dialog_fn(void *vctx, int result)
Replace dlg_error_message() with a non-modal message box. Apart from the specific benefit of non-modality, this also makes it a lot simpler compared to the previous code! I'm not completely sure why I wasn't using the standard gtkdlg.c message box system all along.
2017-11-26 17:05:51 +00:00
{
}
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
void dlg_error_msg(dlgparam *dp, const char *msg)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Replace dlg_error_message() with a non-modal message box. Apart from the specific benefit of non-modality, this also makes it a lot simpler compared to the previous code! I'm not completely sure why I wasn't using the standard gtkdlg.c message box system all along.
2017-11-26 17:05:51 +00:00
create_message_box(
dp->window, "Error", msg,
string_width("Some sort of text about a config-box error message"),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
false, &buttons_ok, trivial_post_dialog_fn, NULL);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
/*
* This function signals to the front end that the dialog's
* processing is completed, and passes an integer value (typically
* a success status).
*/
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
void dlg_end(dlgparam *dp, int value)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
dp->retval = value;
Having created and used uxsel, it actually turns out to be practically trivial to put all the pieces together and create a working prototype of Unix PuTTY! It's missing a lot of things - notably GUI request boxes for host keys and logfiles and so forth, the Event Log, mid-session reconfiguration, session loading and saving, sensible population of the character sets drop-down list and probably other fiddly little things too - but it will put up a config box and then create a GUI window containing an SSH connection to the host you specified, so it's _basically_ there. Woo! [originally from svn r3020]
2003-03-29 19:52:50 +00:00
gtk_widget_destroy(dp->window);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_refresh(dlgcontrol *ctrl, dlgparam *dp)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc;
if (ctrl) {
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (ctrl->handler != NULL)
ctrl->handler(ctrl, dp, dp->data, EVENT_REFRESH);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
for (i = 0; (uc = index234(dp->byctrl, i)) != NULL; i++) {
assert(uc->ctrl != NULL);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (uc->ctrl->handler != NULL)
uc->ctrl->handler(uc->ctrl, dp,
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
dp->data, EVENT_REFRESH);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
void dlg_coloursel_start(dlgcontrol *ctrl, dlgparam *dp, int r, int g, int b)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#if GTK_CHECK_VERSION(3,0,0)
GtkWidget *coloursel =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_color_chooser_dialog_new("Select a colour",
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
GTK_WINDOW(dp->window));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_color_chooser_set_use_alpha(GTK_COLOR_CHOOSER(coloursel), false);
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#else
GtkWidget *okbutton, *cancelbutton;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
GtkWidget *coloursel =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_color_selection_dialog_new("Select a colour");
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
GtkColorSelectionDialog *ccs = GTK_COLOR_SELECTION_DIALOG(coloursel);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
GtkColorSelection *cs = GTK_COLOR_SELECTION(
gtk_color_selection_dialog_get_color_selection(ccs));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_color_selection_set_has_opacity_control(cs, false);
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
dp->coloursel_result.ok = false;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_window_set_modal(GTK_WINDOW(coloursel), true);
GTK 3 prep: use gtk_color_selection_get_current_color(). Replaces the deprecated gtk_color_selection_set_color() which took an array of four doubles (RGBA), and instead takes a 'GdkColor' struct containing four 16-bit integers. For GTK1, we still have to retain the original version.
2015-08-08 16:32:15 +00:00
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#if GTK_CHECK_VERSION(3,0,0)
{
GdkRGBA rgba;
rgba.red = r / 255.0;
rgba.green = g / 255.0;
rgba.blue = b / 255.0;
rgba.alpha = 1.0; /* fully opaque! */
gtk_color_chooser_set_rgba(GTK_COLOR_CHOOSER(coloursel), &rgba);
}
#elif GTK_CHECK_VERSION(2,0,0)
GTK 3 prep: use gtk_color_selection_get_current_color(). Replaces the deprecated gtk_color_selection_set_color() which took an array of four doubles (RGBA), and instead takes a 'GdkColor' struct containing four 16-bit integers. For GTK1, we still have to retain the original version.
2015-08-08 16:32:15 +00:00
{
GdkColor col;
col.red = r * 0x0101;
col.green = g * 0x0101;
col.blue = b * 0x0101;
gtk_color_selection_set_current_color(cs, &col);
}
#else
{
gdouble cvals[4];
cvals[0] = r / 255.0;
cvals[1] = g / 255.0;
cvals[2] = b / 255.0;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cvals[3] = 1.0; /* fully opaque! */
GTK 3 prep: use gtk_color_selection_get_current_color(). Replaces the deprecated gtk_color_selection_set_color() which took an array of four doubles (RGBA), and instead takes a 'GdkColor' struct containing four 16-bit integers. For GTK1, we still have to retain the original version.
2015-08-08 16:32:15 +00:00
gtk_color_selection_set_color(cs, cvals);
}
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
g_object_set_data(G_OBJECT(coloursel), "user-data", (gpointer)uc);
#if GTK_CHECK_VERSION(3,0,0)
g_signal_connect(G_OBJECT(coloursel), "response",
G_CALLBACK(colourchoose_response), (gpointer)dp);
#else
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
#if GTK_CHECK_VERSION(2,0,0)
g_object_get(G_OBJECT(ccs),
"ok-button", &okbutton,
"cancel-button", &cancelbutton,
(const char *)NULL);
#else
okbutton = ccs->ok_button;
cancelbutton = ccs->cancel_button;
#endif
g_object_set_data(G_OBJECT(okbutton), "user-data",
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
(gpointer)coloursel);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
g_object_set_data(G_OBJECT(cancelbutton), "user-data",
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
(gpointer)coloursel);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(okbutton), "clicked",
G_CALLBACK(coloursel_ok), (gpointer)dp);
g_signal_connect(G_OBJECT(cancelbutton), "clicked",
G_CALLBACK(coloursel_cancel), (gpointer)dp);
g_signal_connect_swapped(G_OBJECT(okbutton), "clicked",
G_CALLBACK(gtk_widget_destroy),
(gpointer)coloursel);
g_signal_connect_swapped(G_OBJECT(cancelbutton), "clicked",
G_CALLBACK(gtk_widget_destroy),
(gpointer)coloursel);
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
gtk_widget_show(coloursel);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
bool dlg_coloursel_results(dlgcontrol *ctrl, dlgparam *dp,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int *r, int *g, int *b)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
if (dp->coloursel_result.ok) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*r = dp->coloursel_result.r;
*g = dp->coloursel_result.g;
*b = dp->coloursel_result.b;
return true;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
/* ----------------------------------------------------------------------
* Signal handlers while the dialog box is active.
*/
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
static gboolean widget_focus(GtkWidget *widget, GdkEventFocus *event,
gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, widget);
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *focus;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
if (uc && uc->ctrl)
focus = uc->ctrl;
else
focus = NULL;
if (focus != dp->currfocus) {
dp->lastfocus = dp->currfocus;
dp->currfocus = focus;
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
}
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static void button_clicked(GtkButton *button, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(button));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_ACTION);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
static void button_toggled(GtkToggleButton *tb, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(tb));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_VALCHANGE);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
A nasty GTK signal cascade was causing any edit box whose contents was modified on session load to be blanked. More details in the comment in dlg_editbox_set(). [originally from svn r7161]
2007-01-25 19:47:36 +00:00
static gboolean editbox_key(GtkWidget *widget, GdkEventKey *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
{
/*
* GtkEntry has a nasty habit of eating the Return key, which
* is unhelpful since it doesn't actually _do_ anything with it
* (it calls gtk_widget_activate, but our edit boxes never need
* activating). So I catch Return before GtkEntry sees it, and
* pass it straight on to the parent widget. Effect: hitting
* Return in an edit box will now activate the default button
* in the dialog just like it will everywhere else.
*/
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
GtkWidget *parent = gtk_widget_get_parent(widget);
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
if (event->keyval == GDK_KEY_Return && parent != NULL) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gboolean return_val;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_stop_emission_by_name(G_OBJECT(widget), "key_press_event");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
g_signal_emit_by_name(G_OBJECT(parent), "key_press_event",
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
event, &return_val);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return return_val;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static void editbox_changed(GtkEditable *ed, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
if (!(dp->flags & FLAG_UPDATING_COMBO_LIST)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(ed));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_VALCHANGE);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
}
A nasty GTK signal cascade was causing any edit box whose contents was modified on session load to be blanked. More details in the comment in dlg_editbox_set(). [originally from svn r7161]
2007-01-25 19:47:36 +00:00
static gboolean editbox_lostfocus(GtkWidget *ed, GdkEventFocus *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(ed));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_REFRESH);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
/*
* GTK 1 list box event handlers.
*/
static gboolean listitem_key(GtkWidget *item, GdkEventKey *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data, bool multiple)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
{
GtkAdjustment *adj = GTK_ADJUSTMENT(data);
if (event->keyval == GDK_Up || event->keyval == GDK_KP_Up ||
event->keyval == GDK_Down || event->keyval == GDK_KP_Down ||
event->keyval == GDK_Page_Up || event->keyval == GDK_KP_Page_Up ||
event->keyval == GDK_Page_Down || event->keyval == GDK_KP_Page_Down) {
/*
* Up, Down, PgUp or PgDn have been pressed on a ListItem
* in a list box. So, if the list box is single-selection:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
* - if the list item in question isn't already selected,
* we simply select it.
* - otherwise, we find the next one (or next
* however-far-away) in whichever direction we're going,
* and select that.
* + in this case, we must also fiddle with the
* scrollbar to ensure the newly selected item is
* actually visible.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
* If it's multiple-selection, we do all of the above
* except actually selecting anything, so we move the focus
* and fiddle the scrollbar to follow it.
*/
GtkWidget *list = item->parent;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_stop_emission_by_name(G_OBJECT(item), "key_press_event");
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (!multiple &&
GTK_WIDGET_STATE(item) != GTK_STATE_SELECTED) {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
gtk_list_select_child(GTK_LIST(list), item);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
} else {
int direction =
(event->keyval==GDK_Up || event->keyval==GDK_KP_Up ||
event->keyval==GDK_Page_Up || event->keyval==GDK_KP_Page_Up)
? -1 : +1;
int step =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(event->keyval==GDK_Page_Down ||
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
event->keyval==GDK_KP_Page_Down ||
event->keyval==GDK_Page_Up || event->keyval==GDK_KP_Page_Up)
? 2 : 1;
int i, n;
GList *children, *chead;
chead = children = gtk_container_children(GTK_CONTAINER(list));
n = g_list_length(children);
if (step == 2) {
/*
* Figure out how many list items to a screenful,
* and adjust the step appropriately.
*/
step = 0.5 + adj->page_size * n / (adj->upper - adj->lower);
step--; /* go by one less than that */
}
i = 0;
while (children != NULL) {
if (item == children->data)
break;
children = children->next;
i++;
}
while (step > 0) {
if (direction < 0 && i > 0)
children = children->prev, i--;
else if (direction > 0 && i < n-1)
children = children->next, i++;
step--;
}
if (children && children->data) {
if (!multiple)
gtk_list_select_child(GTK_LIST(list),
GTK_WIDGET(children->data));
gtk_widget_grab_focus(GTK_WIDGET(children->data));
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_adjustment_clamp_page(
adj,
adj->lower + (adj->upper-adj->lower) * i / n,
adj->lower + (adj->upper-adj->lower) * (i+1) / n);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
g_list_free(chead);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
static gboolean listitem_single_key(GtkWidget *item, GdkEventKey *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return listitem_key(item, event, data, false);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
static gboolean listitem_multi_key(GtkWidget *item, GdkEventKey *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return listitem_key(item, event, data, true);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
static gboolean listitem_button_press(GtkWidget *item, GdkEventButton *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(item));
switch (event->type) {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
default:
case GDK_BUTTON_PRESS: uc->nclicks = 1; break;
case GDK_2BUTTON_PRESS: uc->nclicks = 2; break;
case GDK_3BUTTON_PRESS: uc->nclicks = 3; break;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
static gboolean listitem_button_release(GtkWidget *item, GdkEventButton *event,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(item));
if (uc->nclicks>1) {
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_ACTION);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
static void list_selchange(GtkList *list, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(list));
if (!uc) return;
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_SELCHANGE);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
static void draglist_move(struct dlgparam *dp, struct uctrl *uc, int direction)
{
int index = dlg_listbox_index(uc->ctrl, dp);
GList *children = gtk_container_children(GTK_CONTAINER(uc->list));
GtkWidget *child;
if ((index < 0) ||
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(index == 0 && direction < 0) ||
(index == g_list_length(children)-1 && direction > 0)) {
gdk_display_beep(gdk_display_get_default());
return;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
child = g_list_nth_data(children, index);
gtk_widget_ref(child);
gtk_list_clear_items(GTK_LIST(uc->list), index, index+1);
g_list_free(children);
children = NULL;
children = g_list_append(children, child);
gtk_list_insert_items(GTK_LIST(uc->list), children, index + direction);
gtk_list_select_item(GTK_LIST(uc->list), index + direction);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_VALCHANGE);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
static void draglist_up(GtkButton *button, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(button));
draglist_move(dp, uc, -1);
}
static void draglist_down(GtkButton *button, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(button));
draglist_move(dp, uc, +1);
}
#else /* !GTK_CHECK_VERSION(2,0,0) */
/*
* GTK 2 list box event handlers.
*/
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
static void listbox_doubleclick(GtkTreeView *treeview, GtkTreePath *path,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreeViewColumn *column, gpointer data)
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(treeview));
if (uc)
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_ACTION);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
static void listbox_selchange(GtkTreeSelection *treeselection,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
GtkTreeView *tree = gtk_tree_selection_get_tree_view(treeselection);
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(tree));
if (uc)
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_SELCHANGE);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
struct draglist_valchange_ctx {
struct uctrl *uc;
struct dlgparam *dp;
};
static gboolean draglist_valchange(gpointer data)
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
{
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
struct draglist_valchange_ctx *ctx =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(struct draglist_valchange_ctx *)data;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
ctx->uc->ctrl->handler(ctx->uc->ctrl, ctx->dp,
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
ctx->dp->data, EVENT_VALCHANGE);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
sfree(ctx);
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
static void listbox_reorder(GtkTreeModel *treemodel, GtkTreePath *path,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreeIter *iter, gpointer data)
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
gpointer tree;
struct uctrl *uc;
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
if (dp->flags & FLAG_UPDATING_LISTBOX)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return; /* not a user drag operation */
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
tree = g_object_get_data(G_OBJECT(treemodel), "user-data");
uc = dlg_find_bywidget(dp, GTK_WIDGET(tree));
if (uc) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* We should cause EVENT_VALCHANGE on the list box, now
* that its rows have been reordered. However, the GTK 2
* docs say that at the point this signal is received the
* new row might not have actually been filled in yet.
*
* (So what smegging use is it then, eh? Don't suppose it
* occurred to you at any point that letting the
* application know _after_ the reordering was compelete
* might be helpful to someone?)
*
* To get round this, I schedule an idle function, which I
* hope won't be called until the main event loop is
* re-entered after the drag-and-drop handler has finished
* furtling with the list store.
*/
struct draglist_valchange_ctx *ctx =
snew(struct draglist_valchange_ctx);
ctx->uc = uc;
ctx->dp = dp;
g_idle_add(draglist_valchange, ctx);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
}
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif /* !GTK_CHECK_VERSION(2,0,0) */
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
static void menuitem_activate(GtkMenuItem *item, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
GtkWidget *menushell = GTK_WIDGET(item)->parent;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
gpointer optmenu = g_object_get_data(G_OBJECT(menushell), "user-data");
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(optmenu));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_SELCHANGE);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#else
static void droplist_selchange(GtkComboBox *combo, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(combo));
if (uc)
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_SELCHANGE);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
}
#endif /* !GTK_CHECK_VERSION(2,4,0) */
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
static void filechoose_emit_value(struct dlgparam *dp, struct uctrl *uc,
const char *name)
{
if (uc->entry) {
gtk_entry_set_text(GTK_ENTRY(uc->entry), name);
} else {
uc->textvalue = name;
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_ACTION);
uc->textvalue = NULL;
}
}
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
#ifdef USE_GTK_FILE_CHOOSER_DIALOG
static void filechoose_response(GtkDialog *dialog, gint response,
gpointer data)
{
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
struct dlgparam *dp = (struct dlgparam *)data;
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
struct uctrl *uc = g_object_get_data(G_OBJECT(dialog), "user-data");
if (response == GTK_RESPONSE_ACCEPT) {
gchar *name = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(dialog));
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
filechoose_emit_value(dp, uc, name);
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
g_free(name);
}
gtk_widget_destroy(GTK_WIDGET(dialog));
}
#else
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static void filesel_ok(GtkButton *button, gpointer data)
{
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
struct dlgparam *dp = (struct dlgparam *)data;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
gpointer filesel = g_object_get_data(G_OBJECT(button), "user-data");
struct uctrl *uc = g_object_get_data(G_OBJECT(filesel), "user-data");
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
const char *name = gtk_file_selection_get_filename(
GTK_FILE_SELECTION(filesel));
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
filechoose_emit_value(dp, uc, name);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static void fontsel_ok(GtkButton *button, gpointer data)
{
Having created and used uxsel, it actually turns out to be practically trivial to put all the pieces together and create a working prototype of Unix PuTTY! It's missing a lot of things - notably GUI request boxes for host keys and logfiles and so forth, the Event Log, mid-session reconfiguration, session loading and saving, sensible population of the character sets drop-down list and probably other fiddly little things too - but it will put up a config box and then create a GUI window containing an SSH connection to the host you specified, so it's _basically_ there. Woo! [originally from svn r3020]
2003-03-29 19:52:50 +00:00
/* struct dlgparam *dp = (struct dlgparam *)data; */
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
gpointer fontsel = g_object_get_data(G_OBJECT(button), "user-data");
struct uctrl *uc = g_object_get_data(G_OBJECT(fontsel), "user-data");
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
const char *name = gtk_font_selection_dialog_get_font_name(
GTK_FONT_SELECTION_DIALOG(fontsel));
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
gtk_entry_set_text(GTK_ENTRY(uc->entry), name);
#else
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
unifontsel *fontsel = (unifontsel *)g_object_get_data(
G_OBJECT(button), "user-data");
Unified font selector dialog box. _Extremely_ unfinished - there's a sizable TODO at the top of gtkfont.c - but it's basically functional enough to select fonts of both types, so I'm checking it in now before I accidentally break it. [originally from svn r7938]
2008-03-25 21:49:14 +00:00
struct uctrl *uc = (struct uctrl *)fontsel->user_data;
char *name = unifontsel_get_name(fontsel);
Deal with the possibility of no valid font being selected at all during an entire run of unifontsel (because unifontsel_set_name was either not called at all, or called with a name that didn't correspond to any known font). In this situation we grey out the OK button until a valid font is selected, and we have unifontsel_get_name return NULL rather than failing an assertion if it should be called in that state. The current client code in gtkdlg.c should never encounter a NULL return, since it only calls it after the OK button is clicked, but I've stuck an assertion in there too on general principles. [originally from svn r7953]
2008-03-29 14:21:25 +00:00
assert(name); /* should always be ok after OK pressed */
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
gtk_entry_set_text(GTK_ENTRY(uc->entry), name);
Unified font selector dialog box. _Extremely_ unfinished - there's a sizable TODO at the top of gtkfont.c - but it's basically functional enough to select fonts of both types, so I'm checking it in now before I accidentally break it. [originally from svn r7938]
2008-03-25 21:49:14 +00:00
sfree(name);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#if GTK_CHECK_VERSION(3,0,0)
static void colourchoose_response(GtkDialog *dialog,
gint response_id, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = g_object_get_data(G_OBJECT(dialog), "user-data");
if (response_id == GTK_RESPONSE_OK) {
GdkRGBA rgba;
gtk_color_chooser_get_rgba(GTK_COLOR_CHOOSER(dialog), &rgba);
dp->coloursel_result.r = (int) (255 * rgba.red);
dp->coloursel_result.g = (int) (255 * rgba.green);
dp->coloursel_result.b = (int) (255 * rgba.blue);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
dp->coloursel_result.ok = true;
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
} else {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
dp->coloursel_result.ok = false;
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
}
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_CALLBACK);
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
gtk_widget_destroy(GTK_WIDGET(dialog));
}
#else /* GTK 1/2 coloursel response handlers */
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static void coloursel_ok(GtkButton *button, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
gpointer coloursel = g_object_get_data(G_OBJECT(button), "user-data");
struct uctrl *uc = g_object_get_data(G_OBJECT(coloursel), "user-data");
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
GTK 3 prep: use gtk_color_selection_get_current_color(). Replaces the deprecated gtk_color_selection_set_color() which took an array of four doubles (RGBA), and instead takes a 'GdkColor' struct containing four 16-bit integers. For GTK1, we still have to retain the original version.
2015-08-08 16:32:15 +00:00
#if GTK_CHECK_VERSION(2,0,0)
{
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
GtkColorSelection *cs = GTK_COLOR_SELECTION(
gtk_color_selection_dialog_get_color_selection(
GTK_COLOR_SELECTION_DIALOG(coloursel)));
GTK 3 prep: use gtk_color_selection_get_current_color(). Replaces the deprecated gtk_color_selection_set_color() which took an array of four doubles (RGBA), and instead takes a 'GdkColor' struct containing four 16-bit integers. For GTK1, we still have to retain the original version.
2015-08-08 16:32:15 +00:00
GdkColor col;
gtk_color_selection_get_current_color(cs, &col);
dp->coloursel_result.r = col.red / 0x0100;
dp->coloursel_result.g = col.green / 0x0100;
dp->coloursel_result.b = col.blue / 0x0100;
}
#else
{
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
GtkColorSelection *cs = GTK_COLOR_SELECTION(
gtk_color_selection_dialog_get_color_selection(
GTK_COLOR_SELECTION_DIALOG(coloursel)));
GTK 3 prep: use gtk_color_selection_get_current_color(). Replaces the deprecated gtk_color_selection_set_color() which took an array of four doubles (RGBA), and instead takes a 'GdkColor' struct containing four 16-bit integers. For GTK1, we still have to retain the original version.
2015-08-08 16:32:15 +00:00
gdouble cvals[4];
gtk_color_selection_get_color(cs, cvals);
dp->coloursel_result.r = (int) (255 * cvals[0]);
dp->coloursel_result.g = (int) (255 * cvals[1]);
dp->coloursel_result.b = (int) (255 * cvals[2]);
}
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
dp->coloursel_result.ok = true;
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_CALLBACK);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
static void coloursel_cancel(GtkButton *button, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
gpointer coloursel = g_object_get_data(G_OBJECT(button), "user-data");
struct uctrl *uc = g_object_get_data(G_OBJECT(coloursel), "user-data");
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
dp->coloursel_result.ok = false;
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->ctrl->handler(uc->ctrl, dp, dp->data, EVENT_CALLBACK);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
In GTK3, use the new GtkColorChooserDialog. This replaces the old GtkColorSelectionDialog, and has the convenience advantage that the actual chooser (with all the 'set colour', 'get colour' methods) and the containing dialog box are now the same object implementing multiple interfaces, so I don't keep having to call 'get me the underlying chooser for this dialog' accessors. Also you now hook into both the OK and Cancel buttons (and all other response codes) at the same time with a single event.
2015-08-22 13:49:02 +00:00
#endif /* end of coloursel response handlers */
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
static void filefont_clicked(GtkButton *button, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, GTK_WIDGET(button));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (uc->ctrl->type == CTRL_FILESELECT) {
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
#ifdef USE_GTK_FILE_CHOOSER_DIALOG
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
GtkWidget *filechoose = gtk_file_chooser_dialog_new(
uc->ctrl->fileselect.title, GTK_WINDOW(dp->window),
(uc->ctrl->fileselect.for_writing ?
GTK_FILE_CHOOSER_ACTION_SAVE :
GTK_FILE_CHOOSER_ACTION_OPEN),
STANDARD_CANCEL_LABEL, GTK_RESPONSE_CANCEL,
STANDARD_OPEN_LABEL, GTK_RESPONSE_ACCEPT,
(const gchar *)NULL);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_set_modal(GTK_WINDOW(filechoose), true);
g_object_set_data(G_OBJECT(filechoose), "user-data", (gpointer)uc);
g_signal_connect(G_OBJECT(filechoose), "response",
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
G_CALLBACK(filechoose_response), (gpointer)dp);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_show(filechoose);
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *filesel =
gtk_file_selection_new(uc->ctrl->fileselect.title);
gtk_window_set_modal(GTK_WINDOW(filesel), true);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
g_object_set_data(
G_OBJECT(GTK_FILE_SELECTION(filesel)->ok_button), "user-data",
(gpointer)filesel);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set_data(G_OBJECT(filesel), "user-data", (gpointer)uc);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
g_signal_connect(
G_OBJECT(GTK_FILE_SELECTION(filesel)->ok_button), "clicked",
G_CALLBACK(filesel_ok), (gpointer)dp);
g_signal_connect_swapped(
G_OBJECT(GTK_FILE_SELECTION(filesel)->ok_button), "clicked",
G_CALLBACK(gtk_widget_destroy), (gpointer)filesel);
g_signal_connect_swapped(
G_OBJECT(GTK_FILE_SELECTION(filesel)->cancel_button), "clicked",
G_CALLBACK(gtk_widget_destroy), (gpointer)filesel);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_show(filesel);
GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog. I've put in a special #define to control this selection, in case I decide that for reasons of taste I'd prefer to switch back to GtkFileSelection in GTK2 which supports both!
2015-08-08 16:34:25 +00:00
#endif
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (uc->ctrl->type == CTRL_FONTSELECT) {
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
const gchar *fontname = gtk_entry_get_text(GTK_ENTRY(uc->entry));
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Use the GTK 1 standard font selector.
*/
gchar *spacings[] = { "c", "m", NULL };
GtkWidget *fontsel =
gtk_font_selection_dialog_new("Select a font");
gtk_window_set_modal(GTK_WINDOW(fontsel), true);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_font_selection_dialog_set_filter(
GTK_FONT_SELECTION_DIALOG(fontsel),
GTK_FONT_FILTER_BASE, GTK_FONT_ALL,
NULL, NULL, NULL, NULL, spacings, NULL);
if (!gtk_font_selection_dialog_set_font_name(
GTK_FONT_SELECTION_DIALOG(fontsel), fontname)) {
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
/*
* If the font name wasn't found as it was, try opening
* it and extracting its FONT property. This should
* have the effect of mapping short aliases into true
* XLFDs.
*/
GdkFont *font = gdk_font_load(fontname);
if (font) {
XFontStruct *xfs = GDK_FONT_XFONT(font);
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
Display *disp = get_x11_display();
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Atom fontprop = XInternAtom(disp, "FONT", False);
unsigned long ret;
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
assert(disp); /* this is GTK1! */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gdk_font_ref(font);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (XGetFontProperty(xfs, fontprop, &ret)) {
char *name = XGetAtomName(disp, (Atom)ret);
if (name)
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_font_selection_dialog_set_font_name(
GTK_FONT_SELECTION_DIALOG(fontsel), name);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
}
gdk_font_unref(font);
}
}
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
g_object_set_data(
G_OBJECT(GTK_FONT_SELECTION_DIALOG(fontsel)->ok_button),
"user-data", (gpointer)fontsel);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set_data(G_OBJECT(fontsel), "user-data", (gpointer)uc);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
g_signal_connect(
G_OBJECT(GTK_FONT_SELECTION_DIALOG(fontsel)->ok_button),
"clicked", G_CALLBACK(fontsel_ok), (gpointer)dp);
g_signal_connect_swapped(
G_OBJECT(GTK_FONT_SELECTION_DIALOG(fontsel)->ok_button),
"clicked", G_CALLBACK(gtk_widget_destroy),
(gpointer)fontsel);
g_signal_connect_swapped(
G_OBJECT(GTK_FONT_SELECTION_DIALOG(fontsel)->cancel_button),
"clicked", G_CALLBACK(gtk_widget_destroy),
(gpointer)fontsel);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_show(fontsel);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else /* !GTK_CHECK_VERSION(2,0,0) */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* Use the unifontsel code provided in unifont.c.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*/
unifontsel *fontsel = unifontsel_new("Select a font");
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_set_modal(fontsel->window, true);
unifontsel_set_name(fontsel, fontname);
Unified font selector dialog box. _Extremely_ unfinished - there's a sizable TODO at the top of gtkfont.c - but it's basically functional enough to select fonts of both types, so I'm checking it in now before I accidentally break it. [originally from svn r7938]
2008-03-25 21:49:14 +00:00
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set_data(G_OBJECT(fontsel->ok_button),
"user-data", (gpointer)fontsel);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fontsel->user_data = uc;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(fontsel->ok_button), "clicked",
G_CALLBACK(fontsel_ok), (gpointer)dp);
g_signal_connect_swapped(G_OBJECT(fontsel->ok_button), "clicked",
G_CALLBACK(unifontsel_destroy),
(gpointer)fontsel);
g_signal_connect_swapped(G_OBJECT(fontsel->cancel_button),"clicked",
G_CALLBACK(unifontsel_destroy),
(gpointer)fontsel);
Unified font selector dialog box. _Extremely_ unfinished - there's a sizable TODO at the top of gtkfont.c - but it's basically functional enough to select fonts of both types, so I'm checking it in now before I accidentally break it. [originally from svn r7938]
2008-03-25 21:49:14 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_show(GTK_WIDGET(fontsel->window));
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif /* !GTK_CHECK_VERSION(2,0,0) */
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
}
}
In GTK3, omit our GTK 1/2 workaround for wrapping labels. Now we're properly implementing the GTK3 height-for-width layout model, this bodge is no longer necessary.
2015-08-23 14:01:07 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
static void label_sizealloc(GtkWidget *widget, GtkAllocation *alloc,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
struct uctrl *uc = dlg_find_bywidget(dp, widget);
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
gtk_widget_set_size_request(uc->text, alloc->width, -1);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
gtk_label_set_text(GTK_LABEL(uc->text), uc->ctrl->label);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_handler_disconnect(G_OBJECT(uc->text), uc->textsig);
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
}
In GTK3, omit our GTK 1/2 workaround for wrapping labels. Now we're properly implementing the GTK3 height-for-width layout model, this bodge is no longer necessary.
2015-08-23 14:01:07 +00:00
#endif
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
/* ----------------------------------------------------------------------
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
* This function does the main layout work: it reads a controlset,
* it creates the relevant GTK controls, and returns a GtkWidget
* containing the result. (This widget might be a title of some
* sort, it might be a Columns containing many controls, or it
* might be a GtkFrame containing a Columns; whatever it is, it's
* definitely a GtkWidget and should probably be added to a
* GtkVbox.)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
* `win' is required for setting the default button. If it is
* non-NULL, all buttons created will be default-capable (so they
* have extra space round them for the default highlight).
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
*/
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
GtkWidget *layout_ctrls(
struct dlgparam *dp, struct selparam *sp, struct Shortcuts *scs,
struct controlset *s, GtkWindow *win)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Columns *cols;
GtkWidget *ret;
int i;
Add some more miscellaneous asserts. These clarify matters for static checkers (not to mention humans), and seem inexpensive enough not to worry about adding.
2018-12-01 14:13:37 +00:00
if (!s->boxname) {
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/* This controlset is a panel title. */
Add some more miscellaneous asserts. These clarify matters for static checkers (not to mention humans), and seem inexpensive enough not to worry about adding.
2018-12-01 14:13:37 +00:00
assert(s->boxtitle);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
return gtk_label_new(s->boxtitle);
}
/*
* Otherwise, we expect to be laying out actual controls, so
* we'll start by creating a Columns for the purpose.
*/
cols = COLUMNS(columns_new(4));
ret = GTK_WIDGET(cols);
gtk_widget_show(ret);
/*
* Create a containing frame if we have a box name.
*/
if (*s->boxname) {
ret = gtk_frame_new(s->boxtitle); /* NULL is valid here */
gtk_container_set_border_width(GTK_CONTAINER(cols), 4);
gtk_container_add(GTK_CONTAINER(ret), GTK_WIDGET(cols));
gtk_widget_show(ret);
}
/*
* Now iterate through the controls themselves, create them,
* and add them to the Columns.
*/
for (i = 0; i < s->ncontrols; i++) {
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *ctrl = s->ctrls[i];
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct uctrl *uc;
bool left = false;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
GtkWidget *w = NULL;
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
switch (ctrl->type) {
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case CTRL_COLUMNS: {
static const int simplecols[1] = { 100 };
columns_set_cols(cols, ctrl->columns.ncols,
(ctrl->columns.percentages ?
ctrl->columns.percentages : simplecols));
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
continue; /* no actual control created */
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case CTRL_TABDELAY: {
struct uctrl *uc = dlg_find_byctrl(dp, ctrl->tabdelay.ctrl);
if (uc)
columns_taborder_last(cols, uc->toplevel);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
continue; /* no actual control created */
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc = snew(struct uctrl);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
uc->sp = sp;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->ctrl = ctrl;
uc->buttons = NULL;
uc->entry = NULL;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->list = uc->menu = uc->optmenu = NULL;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->combo = NULL;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
#if GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->treeview = NULL;
uc->listmodel = NULL;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->button = uc->text = NULL;
uc->label = NULL;
Patch from John Sullivan: process double-clicks in the session list box on button-up rather than button-down. The effect of this is that if a saved session is already selected in the list box and then you double-click it, it will open rather than beeping annoyingly. [originally from svn r7414]
2007-03-27 18:16:36 +00:00
uc->nclicks = 0;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
switch (ctrl->type) {
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
case CTRL_BUTTON:
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
w = gtk_button_new_with_label(ctrl->label);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (win) {
gtk_widget_set_can_default(w, true);
if (ctrl->button.isdefault)
gtk_window_set_default(win, w);
if (ctrl->button.iscancel)
dp->cancelbutton = w;
}
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(w), "clicked",
G_CALLBACK(button_clicked), dp);
g_signal_connect(G_OBJECT(w), "focus_in_event",
G_CALLBACK(widget_focus), dp);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
shortcut_add(scs, gtk_bin_get_child(GTK_BIN(w)),
ctrl->button.shortcut, SHORTCUT_UCTRL, uc);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
break;
case CTRL_CHECKBOX:
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
w = gtk_check_button_new_with_label(ctrl->label);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(w), "toggled",
G_CALLBACK(button_toggled), dp);
g_signal_connect(G_OBJECT(w), "focus_in_event",
G_CALLBACK(widget_focus), dp);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
shortcut_add(scs, gtk_bin_get_child(GTK_BIN(w)),
ctrl->checkbox.shortcut, SHORTCUT_UCTRL, uc);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
left = true;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case CTRL_RADIO: {
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
* Radio buttons get to go inside their own Columns, no
* matter what.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
gint i, *percentages;
GSList *group;
w = columns_new(0);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (ctrl->label) {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
GtkWidget *label = gtk_label_new(ctrl->label);
columns_add(COLUMNS(w), label, 0, 1);
columns_force_left_align(COLUMNS(w), label);
gtk_widget_show(label);
shortcut_add(scs, label, ctrl->radio.shortcut,
SHORTCUT_UCTRL, uc);
uc->label = label;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
percentages = g_new(gint, ctrl->radio.ncolumns);
for (i = 0; i < ctrl->radio.ncolumns; i++) {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
percentages[i] =
((100 * (i+1) / ctrl->radio.ncolumns) -
100 * i / ctrl->radio.ncolumns);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
columns_set_cols(COLUMNS(w), ctrl->radio.ncolumns,
percentages);
g_free(percentages);
group = NULL;
uc->nbuttons = ctrl->radio.nbuttons;
uc->buttons = snewn(uc->nbuttons, GtkWidget *);
for (i = 0; i < ctrl->radio.nbuttons; i++) {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
GtkWidget *b;
gint colstart;
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
b = gtk_radio_button_new_with_label(
group, ctrl->radio.buttons[i]);
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
uc->buttons[i] = b;
group = gtk_radio_button_get_group(GTK_RADIO_BUTTON(b));
colstart = i % ctrl->radio.ncolumns;
columns_add(COLUMNS(w), b, colstart,
(i == ctrl->radio.nbuttons-1 ?
ctrl->radio.ncolumns - colstart : 1));
columns_force_left_align(COLUMNS(w), b);
gtk_widget_show(b);
g_signal_connect(G_OBJECT(b), "toggled",
G_CALLBACK(button_toggled), dp);
g_signal_connect(G_OBJECT(b), "focus_in_event",
G_CALLBACK(widget_focus), dp);
if (ctrl->radio.shortcuts) {
shortcut_add(scs, gtk_bin_get_child(GTK_BIN(b)),
ctrl->radio.shortcuts[i],
SHORTCUT_UCTRL, uc);
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case CTRL_EDITBOX: {
GtkWidget *signalobject;
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (ctrl->editbox.has_list) {
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
/*
* GTK 1 combo box.
*/
w = gtk_combo_new();
gtk_combo_set_value_in_list(GTK_COMBO(w), false, true);
uc->entry = GTK_COMBO(w)->entry;
uc->list = GTK_COMBO(w)->list;
signalobject = uc->entry;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
/*
* GTK 2 combo box.
*/
uc->listmodel = gtk_list_store_new(2, G_TYPE_INT,
G_TYPE_STRING);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
w = gtk_combo_box_new_with_model_and_entry(
GTK_TREE_MODEL(uc->listmodel));
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
g_object_set(G_OBJECT(w), "entry-text-column", 1,
(const char *)NULL);
/* We cannot support password combo boxes. */
assert(!ctrl->editbox.password);
uc->combo = w;
signalobject = uc->combo;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#endif
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
} else {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
w = gtk_entry_new();
if (ctrl->editbox.password)
gtk_entry_set_visibility(GTK_ENTRY(w), false);
uc->entry = w;
signalobject = w;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
GTK: remove 'entrysig' in struct uctrl. The only *use* of it was removed in commit 6a743399b03e3d6, where instead of blocking the GTK signal that caused a string to be overwritten, I switched to making a temporary copy of the string. But I didn't notice that the declaration and assignments could be cleaned up too.
2022-06-23 18:04:43 +00:00
g_signal_connect(G_OBJECT(signalobject), "changed",
G_CALLBACK(editbox_changed), dp);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
g_signal_connect(G_OBJECT(signalobject), "key_press_event",
G_CALLBACK(editbox_key), dp);
g_signal_connect(G_OBJECT(signalobject), "focus_in_event",
G_CALLBACK(widget_focus), dp);
g_signal_connect(G_OBJECT(signalobject), "focus_out_event",
G_CALLBACK(editbox_lostfocus), dp);
g_signal_connect(G_OBJECT(signalobject), "focus_out_event",
G_CALLBACK(editbox_lostfocus), dp);
Use GTK3's method of setting GtkEntry min width. The config box setup code wants a lot of very narrow edit boxes, so it decreases their minimum width from the GTK default of 150 pixels. In GTK 3, we have to do this using gtk_entry_set_width_chars() rather than gtk_widget_set_size_request() as we were previously using, or it won't work. This change by itself seems to restore the GTK3 config box to a sensible layout, in spite of the fact that my Columns layout class is still doing all its size allocation the GTK2 way, with no attention paid to the shiny new GTK3 height-for-width system.
2015-08-22 09:37:48 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
/*
* Edit boxes, for some strange reason, have a minimum
* width of 150 in GTK 1.2. We don't want this - we'd
* rather the edit boxes acquired their natural width
* from the column layout of the rest of the box.
*/
{
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
GtkRequisition req;
gtk_widget_size_request(w, &req);
gtk_widget_set_size_request(w, 10, req.height);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Use GTK3's method of setting GtkEntry min width. The config box setup code wants a lot of very narrow edit boxes, so it decreases their minimum width from the GTK default of 150 pixels. In GTK 3, we have to do this using gtk_entry_set_width_chars() rather than gtk_widget_set_size_request() as we were previously using, or it won't work. This change by itself seems to restore the GTK3 config box to a sensible layout, in spite of the fact that my Columns layout class is still doing all its size allocation the GTK2 way, with no attention paid to the shiny new GTK3 height-for-width system.
2015-08-22 09:37:48 +00:00
#else
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
/*
* In GTK 3, this is still true, but there's a special
* method for GtkEntry in particular to fix it.
*/
if (GTK_IS_ENTRY(w))
gtk_entry_set_width_chars(GTK_ENTRY(w), 1);
Use GTK3's method of setting GtkEntry min width. The config box setup code wants a lot of very narrow edit boxes, so it decreases their minimum width from the GTK default of 150 pixels. In GTK 3, we have to do this using gtk_entry_set_width_chars() rather than gtk_widget_set_size_request() as we were previously using, or it won't work. This change by itself seems to restore the GTK3 config box to a sensible layout, in spite of the fact that my Columns layout class is still doing all its size allocation the GTK2 way, with no attention paid to the shiny new GTK3 height-for-width system.
2015-08-22 09:37:48 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (ctrl->label) {
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
GtkWidget *label;
label = gtk_label_new(ctrl->label);
shortcut_add(scs, label, ctrl->editbox.shortcut,
SHORTCUT_FOCUS, uc->entry);
if (ctrl->editbox.percentwidth == 100) {
columns_add(cols, label,
COLUMN_START(ctrl->column),
COLUMN_SPAN(ctrl->column));
columns_force_left_align(cols, label);
} else {
GtkWidget *container = columns_new(4);
gint percentages[2];
percentages[1] = ctrl->editbox.percentwidth;
percentages[0] = 100 - ctrl->editbox.percentwidth;
columns_set_cols(COLUMNS(container), 2, percentages);
columns_add(COLUMNS(container), label, 0, 1);
columns_force_left_align(COLUMNS(container), label);
columns_add(COLUMNS(container), w, 1, 1);
columns_align_next_to(COLUMNS(container), label, w);
gtk_widget_show(w);
w = container;
}
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
gtk_widget_show(label);
uc->label = label;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
case CTRL_FILESELECT:
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case CTRL_FONTSELECT: {
GtkWidget *ww;
Unix: stop accessing ctrl->fileselect for font selectors. The setup code for CTRL_FILESELECT and CTRL_FONTSELECT is shared, which means it's a mistake to test ctrl->fileselect.just_button in it without first checking which control type we're actually dealing with. UBsan picks this up by complaining that the just_button field contains some byte value that's illegal for a boolean. I think it's also the cause of an intermittent assertion failure reported recently, in which dlg_fontsel_set finds that uc->entry is NULL when it never ought to be. If the byte from the wrong union branch happened to be 0 by sheer bad luck, that could give rise to exactly that failure.
2022-10-28 16:49:59 +00:00
bool just_button = (ctrl->type == CTRL_FILESELECT &&
ctrl->fileselect.just_button);
if (!just_button) {
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
const char *browsebtn =
(ctrl->type == CTRL_FILESELECT ?
"Browse..." : "Change...");
gint percentages[] = { 75, 25 };
w = columns_new(4);
columns_set_cols(COLUMNS(w), 2, percentages);
if (ctrl->label) {
ww = gtk_label_new(ctrl->label);
columns_add(COLUMNS(w), ww, 0, 2);
columns_force_left_align(COLUMNS(w), ww);
gtk_widget_show(ww);
shortcut_add(scs, ww,
(ctrl->type == CTRL_FILESELECT ?
ctrl->fileselect.shortcut :
ctrl->fontselect.shortcut),
SHORTCUT_UCTRL, uc);
uc->label = ww;
}
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
uc->entry = ww = gtk_entry_new();
Another GTK3 fix for GtkEntry width. When I committed 5e738877b the other day, I missed another case of the same thing in the file/font selector handling.
2015-08-24 18:04:37 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
{
GtkRequisition req;
gtk_widget_size_request(ww, &req);
gtk_widget_set_size_request(ww, 10, req.height);
}
Another GTK3 fix for GtkEntry width. When I committed 5e738877b the other day, I missed another case of the same thing in the file/font selector handling.
2015-08-24 18:04:37 +00:00
#else
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
gtk_entry_set_width_chars(GTK_ENTRY(ww), 1);
Another GTK3 fix for GtkEntry width. When I committed 5e738877b the other day, I missed another case of the same thing in the file/font selector handling.
2015-08-24 18:04:37 +00:00
#endif
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
columns_add(COLUMNS(w), ww, 0, 1);
gtk_widget_show(ww);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
uc->button = ww = gtk_button_new_with_label(browsebtn);
columns_add(COLUMNS(w), ww, 1, 1);
gtk_widget_show(ww);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
columns_align_next_to(COLUMNS(w), uc->entry, uc->button);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
g_signal_connect(G_OBJECT(uc->entry), "key_press_event",
G_CALLBACK(editbox_key), dp);
GTK: remove 'entrysig' in struct uctrl. The only *use* of it was removed in commit 6a743399b03e3d6, where instead of blocking the GTK signal that caused a string to be overwritten, I switched to making a temporary copy of the string. But I didn't notice that the declaration and assignments could be cleaned up too.
2022-06-23 18:04:43 +00:00
g_signal_connect(G_OBJECT(uc->entry), "changed",
G_CALLBACK(editbox_changed), dp);
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
g_signal_connect(G_OBJECT(uc->entry), "focus_in_event",
G_CALLBACK(widget_focus), dp);
} else {
uc->button = w = gtk_button_new_with_label(ctrl->label);
shortcut_add(scs, gtk_bin_get_child(GTK_BIN(w)),
ctrl->fileselect.shortcut, SHORTCUT_UCTRL, uc);
gtk_widget_show(w);
}
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
g_signal_connect(G_OBJECT(uc->button), "focus_in_event",
G_CALLBACK(widget_focus), dp);
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
g_signal_connect(G_OBJECT(uc->button), "clicked",
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
G_CALLBACK(filefont_clicked), dp);
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
case CTRL_LISTBOX:
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* First construct the list data store, with the right
* number of columns.
*/
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
# if !GTK_CHECK_VERSION(2,4,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* (For GTK 2.0 to 2.3, we do this for full listboxes only,
* because combo boxes are still done the old GTK1 way.) */
if (ctrl->listbox.height > 0)
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
# endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
GType *types;
int i;
int cols;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cols = ctrl->listbox.ncols;
cols = cols ? cols : 1;
types = snewn(1 + cols, GType);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
types[0] = G_TYPE_INT;
for (i = 0; i < cols; i++)
types[i+1] = G_TYPE_STRING;
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->listmodel = gtk_list_store_newv(1 + cols, types);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(types);
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* See if it's a drop-down list (non-editable combo
* box).
*/
if (ctrl->listbox.height == 0) {
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* GTK1 and early-GTK2 option-menu style of
* drop-down list.
*/
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
uc->optmenu = w = gtk_option_menu_new();
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->menu = gtk_menu_new();
gtk_option_menu_set_menu(GTK_OPTION_MENU(w), uc->menu);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set_data(G_OBJECT(uc->menu), "user-data",
(gpointer)uc->optmenu);
g_signal_connect(G_OBJECT(uc->optmenu), "focus_in_event",
G_CALLBACK(widget_focus), dp);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Late-GTK2 style using a GtkComboBox.
*/
GtkCellRenderer *cr;
/*
* Create a non-editable GtkComboBox (that is, not
* its subclass GtkComboBoxEntry).
*/
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
w = gtk_combo_box_new_with_model(
GTK_TREE_MODEL(uc->listmodel));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->combo = w;
/*
* Tell it how to render a list item (i.e. which
* column to look at in the list model).
*/
cr = gtk_cell_renderer_text_new();
gtk_cell_layout_pack_start(GTK_CELL_LAYOUT(w), cr, true);
gtk_cell_layout_set_attributes(GTK_CELL_LAYOUT(w), cr,
"text", 1, NULL);
/*
* And tell it to notify us when the selection
* changes.
*/
g_signal_connect(G_OBJECT(w), "changed",
G_CALLBACK(droplist_selchange), dp);
Add some missing GTK focus-in event handlers. Fixes a behaviour which I intended all along but apparently didn't work before on GTK: if you start PuTTY, _select_ a saved session in the list box but don't hit Load, and then just hit Open, then it will be implicitly loaded and run for you, as a special case to save you an extra button-press. This depends on noticing that the saved-sessions list box last had the focus, for which I need my widget_focus() handler to be called for basically all config widgets so that I can track what _did_ last have focus. Unfortunately, I missed a couple out.
2015-09-26 10:48:21 +00:00
g_signal_connect(G_OBJECT(w), "focus_in_event",
G_CALLBACK(widget_focus), dp);
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
} else {
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* GTK1-style full list box.
*/
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
uc->list = gtk_list_new();
if (ctrl->listbox.multisel == 2) {
gtk_list_set_selection_mode(GTK_LIST(uc->list),
GTK_SELECTION_EXTENDED);
} else if (ctrl->listbox.multisel == 1) {
gtk_list_set_selection_mode(GTK_LIST(uc->list),
GTK_SELECTION_MULTIPLE);
} else {
gtk_list_set_selection_mode(GTK_LIST(uc->list),
GTK_SELECTION_SINGLE);
}
w = gtk_scrolled_window_new(NULL, NULL);
gtk_scrolled_window_add_with_viewport(GTK_SCROLLED_WINDOW(w),
uc->list);
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(w),
GTK_POLICY_NEVER,
GTK_POLICY_AUTOMATIC);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
uc->adj = gtk_scrolled_window_get_vadjustment(
GTK_SCROLLED_WINDOW(w));
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
gtk_widget_show(uc->list);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(uc->list), "selection-changed",
G_CALLBACK(list_selchange), dp);
g_signal_connect(G_OBJECT(uc->list), "focus_in_event",
G_CALLBACK(widget_focus), dp);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
/*
* Adjust the height of the scrolled window to the
* minimum given by the height parameter.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
* This piece of guesswork is a horrid hack based
* on looking inside the GTK 1.2 sources
* (specifically gtkviewport.c, which appears to be
* the widget which provides the border around the
* scrolling area). Anyone lets me know how I can
* do this in a way which isn't at risk from GTK
* upgrades, I'd be grateful.
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
int edge;
edge = GTK_WIDGET(uc->list)->style->klass->ythickness;
Reindent unix/dialog.c. Large chunks of the GTK setup code had a 2-space indent for some reason, in place of the usual 4-space in this code base. I've been meaning to sort it out for ages, because it makes it hard to have a single set of editor settings suitable for the whole code base.
2022-06-23 17:44:07 +00:00
gtk_widget_set_size_request(
w, 10, 2*edge + (ctrl->listbox.height *
get_listitemheight(w)));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
if (ctrl->listbox.draglist) {
/*
* GTK doesn't appear to make it easy to
* implement a proper draggable list; so
* instead I'm just going to have to put an Up
* and a Down button to the right of the actual
* list box. Ah well.
*/
GtkWidget *cols, *button;
static const gint percentages[2] = { 80, 20 };
cols = columns_new(4);
columns_set_cols(COLUMNS(cols), 2, percentages);
columns_add(COLUMNS(cols), w, 0, 1);
gtk_widget_show(w);
button = gtk_button_new_with_label("Up");
columns_add(COLUMNS(cols), button, 1, 1);
gtk_widget_show(button);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(button), "clicked",
G_CALLBACK(draglist_up), dp);
g_signal_connect(G_OBJECT(button), "focus_in_event",
G_CALLBACK(widget_focus), dp);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
button = gtk_button_new_with_label("Down");
columns_add(COLUMNS(cols), button, 1, 1);
gtk_widget_show(button);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(button), "clicked",
G_CALLBACK(draglist_down), dp);
g_signal_connect(G_OBJECT(button), "focus_in_event",
G_CALLBACK(widget_focus), dp);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
w = cols;
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* GTK2 treeview-based full list box.
*/
GtkTreeSelection *sel;
/*
* Create the list box itself, its columns, and
* its containing scrolled window.
*/
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
w = gtk_tree_view_new_with_model(
GTK_TREE_MODEL(uc->listmodel));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
g_object_set_data(G_OBJECT(uc->listmodel), "user-data",
(gpointer)w);
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(w), false);
sel = gtk_tree_view_get_selection(GTK_TREE_VIEW(w));
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_tree_selection_set_mode(
sel, ctrl->listbox.multisel ? GTK_SELECTION_MULTIPLE :
GTK_SELECTION_SINGLE);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->treeview = w;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(w), "row-activated",
G_CALLBACK(listbox_doubleclick), dp);
Add some missing GTK focus-in event handlers. Fixes a behaviour which I intended all along but apparently didn't work before on GTK: if you start PuTTY, _select_ a saved session in the list box but don't hit Load, and then just hit Open, then it will be implicitly loaded and run for you, as a special case to save you an extra button-press. This depends on noticing that the saved-sessions list box last had the focus, for which I need my widget_focus() handler to be called for basically all config widgets so that I can track what _did_ last have focus. Unfortunately, I missed a couple out.
2015-09-26 10:48:21 +00:00
g_signal_connect(G_OBJECT(w), "focus_in_event",
G_CALLBACK(widget_focus), dp);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
g_signal_connect(G_OBJECT(sel), "changed",
G_CALLBACK(listbox_selchange), dp);
if (ctrl->listbox.draglist) {
gtk_tree_view_set_reorderable(GTK_TREE_VIEW(w), true);
g_signal_connect(G_OBJECT(uc->listmodel), "row-inserted",
G_CALLBACK(listbox_reorder), dp);
}
{
int i;
int cols;
cols = ctrl->listbox.ncols;
cols = cols ? cols : 1;
for (i = 0; i < cols; i++) {
GtkTreeViewColumn *column;
Add an option to suppress horizontal scroll bars in list boxes. I'm about to add a list box which expects to contain some very long but uninformative strings, and which is also quite vertically squashed so there's not much room for a horizontal scroll bar to appear in it. So here's an option in the list box specification structure which causes the constructed GTKTreeView to use the 'ellipsize' option for all its cell renderers, i.e. too-long strings are truncated with an ellipsis. Windows needs no change, because its list boxes already work this way. [originally from svn r10219]
2014-09-09 11:46:14 +00:00
GtkCellRenderer *cellrend;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* It appears that GTK 2 doesn't leave us any
* particularly sensible way to honour the
* "percentages" specification in the ctrl
* structure.
*/
Add an option to suppress horizontal scroll bars in list boxes. I'm about to add a list box which expects to contain some very long but uninformative strings, and which is also quite vertically squashed so there's not much room for a horizontal scroll bar to appear in it. So here's an option in the list box specification structure which causes the constructed GTKTreeView to use the 'ellipsize' option for all its cell renderers, i.e. too-long strings are truncated with an ellipsis. Windows needs no change, because its list boxes already work this way. [originally from svn r10219]
2014-09-09 11:46:14 +00:00
cellrend = gtk_cell_renderer_text_new();
if (!ctrl->listbox.hscroll) {
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_set(G_OBJECT(cellrend),
"ellipsize", PANGO_ELLIPSIZE_END,
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
"ellipsize-set", true,
Add a missing cast in g_object_set. When NULL appears in variadic argument lists, it should be cast to the pointer type that the function will be expecting, because otherwise it might end up as a type not even the same size as a pointer.
2015-08-31 13:36:12 +00:00
(const char *)NULL);
Add an option to suppress horizontal scroll bars in list boxes. I'm about to add a list box which expects to contain some very long but uninformative strings, and which is also quite vertically squashed so there's not much room for a horizontal scroll bar to appear in it. So here's an option in the list box specification structure which causes the constructed GTKTreeView to use the 'ellipsize' option for all its cell renderers, i.e. too-long strings are truncated with an ellipsis. Windows needs no change, because its list boxes already work this way. [originally from svn r10219]
2014-09-09 11:46:14 +00:00
}
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
column = gtk_tree_view_column_new_with_attributes(
"heading", cellrend, "text", i+1, (char *)NULL);
gtk_tree_view_column_set_sizing(
column, GTK_TREE_VIEW_COLUMN_GROW_ONLY);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_tree_view_append_column(GTK_TREE_VIEW(w), column);
}
}
{
GtkWidget *scroll;
scroll = gtk_scrolled_window_new(NULL, NULL);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_scrolled_window_set_shadow_type(
GTK_SCROLLED_WINDOW(scroll), GTK_SHADOW_IN);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_show(w);
gtk_container_add(GTK_CONTAINER(scroll), w);
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scroll),
GTK_POLICY_AUTOMATIC,
GTK_POLICY_ALWAYS);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_widget_set_size_request(
scroll, -1,
ctrl->listbox.height * get_listitemheight(w));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
w = scroll;
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
}
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (ctrl->label) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *label, *container;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
label = gtk_label_new(ctrl->label);
Compile fixes for GTK1 after recent work. The whole of get_label_text_dimensions() should have been outside the GTK 2 ifdef; I'd left a gtk_label_set_width_chars() unconditional; and GDK1's gdk_window_set_background() lacks a const in its prototype. Serves me right for not test-compiling in all three versions!
2015-08-25 18:50:23 +00:00
#if GTK_CHECK_VERSION(3,0,0)
In GTK3, omit our GTK 1/2 workaround for wrapping labels. Now we're properly implementing the GTK3 height-for-width layout model, this bodge is no longer necessary.
2015-08-23 14:01:07 +00:00
gtk_label_set_width_chars(GTK_LABEL(label), 3);
Compile fixes for GTK1 after recent work. The whole of get_label_text_dimensions() should have been outside the GTK 2 ifdef; I'd left a gtk_label_set_width_chars() unconditional; and GDK1's gdk_window_set_background() lacks a const in its prototype. Serves me right for not test-compiling in all three versions!
2015-08-25 18:50:23 +00:00
#endif
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
shortcut_add(scs, label, ctrl->listbox.shortcut,
SHORTCUT_UCTRL, uc);
container = columns_new(4);
if (ctrl->listbox.percentwidth == 100) {
columns_add(COLUMNS(container), label, 0, 1);
columns_force_left_align(COLUMNS(container), label);
columns_add(COLUMNS(container), w, 0, 1);
} else {
gint percentages[2];
percentages[1] = ctrl->listbox.percentwidth;
percentages[0] = 100 - ctrl->listbox.percentwidth;
columns_set_cols(COLUMNS(container), 2, percentages);
columns_add(COLUMNS(container), label, 0, 1);
columns_force_left_align(COLUMNS(container), label);
columns_add(COLUMNS(container), w, 1, 1);
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
columns_align_next_to(COLUMNS(container), label, w);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
gtk_widget_show(label);
gtk_widget_show(w);
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
w = container;
uc->label = label;
}
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
case CTRL_TEXT:
In GTK3, omit our GTK 1/2 workaround for wrapping labels. Now we're properly implementing the GTK3 height-for-width layout model, this bodge is no longer necessary.
2015-08-23 14:01:07 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Wrapping text widgets don't sit well with the GTK2
* layout model, in which widgets state a minimum size
* and the whole window then adjusts to the smallest
* size it can sensibly take given its contents. A
* wrapping text widget _has_ no clear minimum size;
* instead it has a range of possibilities. It can be
* one line deep but 2000 wide, or two lines deep and
* 1000 pixels, or three by 867, or four by 500 and so
* on. It can be as short as you like provided you
* don't mind it being wide, or as narrow as you like
* provided you don't mind it being tall.
*
* Therefore, it fits very badly into the layout model.
* Hence the only thing to do is pick a width and let
* it choose its own number of lines. To do this I'm
* going to cheat a little. All new wrapping text
* widgets will be created with a minimal text content
* "X"; then, after the rest of the dialog box is set
* up and its size calculated, the text widgets will be
* told their width and given their real text, which
* will cause the size to be recomputed in the y
* direction (because many of them will expand to more
* than one line).
*/
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
uc->text = w = gtk_label_new("X");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->textsig =
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(w), "size-allocate",
G_CALLBACK(label_sizealloc), dp);
In GTK3, omit our GTK 1/2 workaround for wrapping labels. Now we're properly implementing the GTK3 height-for-width layout model, this bodge is no longer necessary.
2015-08-23 14:01:07 +00:00
#else
/*
* In GTK3, this is all fixed, because the main aim of the
* new 'height-for-width' geometry management is to make
* wrapping labels behave sensibly. So now we can just do
* the obvious thing.
*/
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
uc->text = w = gtk_label_new(uc->ctrl->label);
In GTK3, omit our GTK 1/2 workaround for wrapping labels. Now we're properly implementing the GTK3 height-for-width layout model, this bodge is no longer necessary.
2015-08-23 14:01:07 +00:00
#endif
Fix GTK1 build. Commit 5390aef3fc7deca broke it, because GTK1 has neither gtk_label_set_selectable nor gtk_widget_set_can_focus. Happily, those are both more or less optional (only a minor UI awkwardness arises from not having them), so I'll just condition them out.
2022-05-12 18:57:10 +00:00
#if GTK_CHECK_VERSION(2,0,0)
GTK: make explicit text controls selectable. This doesn't apply to every GtkLabel I instantiate: only the ones constructed as part of implementing the cross-platform CTRL_TEXT. Those labels contain information that the dialog box is deliberately communicating to the user, so it seems a sensible idea to make sure they can be copy-pasted. By default, this also seems to cause them to become able to take the input focus, so I've reverted that. You can select them with the mouse, but I think having them appear in the tab order is an awkwardness too far, since they're not active in any other way.
2022-05-07 10:00:19 +00:00
gtk_label_set_selectable(GTK_LABEL(w), true);
gtk_widget_set_can_focus(w, false);
Fix GTK1 build. Commit 5390aef3fc7deca broke it, because GTK1 has neither gtk_label_set_selectable nor gtk_widget_set_can_focus. Happily, those are both more or less optional (only a minor UI awkwardness arises from not having them), so I'll just condition them out.
2022-05-12 18:57:10 +00:00
#endif
Avoid deprecated gtk_misc_set_alignment(). As of GTK 3.16 (but not in previous GTK 3 versions), there's a new gtk_label_set_xalign which does this job.
2015-08-31 12:57:34 +00:00
align_label_left(GTK_LABEL(w));
Allow CTRL_TEXT controls to be non-wrapping. This is for cases where they're presenting information to the user that wouldn't wrap sensibly anyway (such as an SSH key fingerprint which is mostly all one word), and in which newlines might be significant. On GTK, the implementing widget is still a GtkLabel, but without the wrap flag set, and wrapped in a GtkScrolledWindow in case the text is too wide to fit. On Windows, I've switched to using an edit box instead of a static text control, making it readonly, and borderless via my existing MakeDlgItemBorderless helper function. This doesn't get you an actual scrollbar, but it does mean you can scroll left and right by dragging with the mouse.
2022-05-07 07:23:38 +00:00
gtk_label_set_line_wrap(GTK_LABEL(w), ctrl->text.wrap);
if (!ctrl->text.wrap) {
gtk_widget_show(uc->text);
w = gtk_scrolled_window_new(NULL, NULL);
gtk_container_set_border_width(GTK_CONTAINER(w), 0);
gtk_container_add(GTK_CONTAINER(w), uc->text);
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(w),
GTK_POLICY_AUTOMATIC,
GTK_POLICY_NEVER);
Fix GTK1 build. Commit 5390aef3fc7deca broke it, because GTK1 has neither gtk_label_set_selectable nor gtk_widget_set_can_focus. Happily, those are both more or less optional (only a minor UI awkwardness arises from not having them), so I'll just condition them out.
2022-05-12 18:57:10 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Allow CTRL_TEXT controls to be non-wrapping. This is for cases where they're presenting information to the user that wouldn't wrap sensibly anyway (such as an SSH key fingerprint which is mostly all one word), and in which newlines might be significant. On GTK, the implementing widget is still a GtkLabel, but without the wrap flag set, and wrapped in a GtkScrolledWindow in case the text is too wide to fit. On Windows, I've switched to using an edit box instead of a static text control, making it readonly, and borderless via my existing MakeDlgItemBorderless helper function. This doesn't get you an actual scrollbar, but it does mean you can scroll left and right by dragging with the mouse.
2022-05-07 07:23:38 +00:00
gtk_widget_set_can_focus(w, false);
Fix GTK1 build. Commit 5390aef3fc7deca broke it, because GTK1 has neither gtk_label_set_selectable nor gtk_widget_set_can_focus. Happily, those are both more or less optional (only a minor UI awkwardness arises from not having them), so I'll just condition them out.
2022-05-12 18:57:10 +00:00
#endif
Allow CTRL_TEXT controls to be non-wrapping. This is for cases where they're presenting information to the user that wouldn't wrap sensibly anyway (such as an SSH key fingerprint which is mostly all one word), and in which newlines might be significant. On GTK, the implementing widget is still a GtkLabel, but without the wrap flag set, and wrapped in a GtkScrolledWindow in case the text is too wide to fit. On Windows, I've switched to using an edit box instead of a static text control, making it readonly, and borderless via my existing MakeDlgItemBorderless helper function. This doesn't get you an actual scrollbar, but it does mean you can scroll left and right by dragging with the mouse.
2022-05-07 07:23:38 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
break;
}
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(w != NULL);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
columns_add(cols, w,
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
COLUMN_START(ctrl->column),
COLUMN_SPAN(ctrl->column));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (left)
columns_force_left_align(cols, w);
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (ctrl->align_next_to) {
dialog system: add a side-by-side alignment feature. This will let us put two controls side by side (e.g. in disjoint columns of a multi-col layout) and indicate that instead of the default behaviour of aligning their top edges, their centreline (or, even better if available, font baseline) should be aligned. NFC: nothing uses this yet.
2021-04-03 16:45:31 +00:00
struct uctrl *uc2 = dlg_find_byctrl(
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
dp, ctrl->align_next_to);
dialog system: add a side-by-side alignment feature. This will let us put two controls side by side (e.g. in disjoint columns of a multi-col layout) and indicate that instead of the default behaviour of aligning their top edges, their centreline (or, even better if available, font baseline) should be aligned. NFC: nothing uses this yet.
2021-04-03 16:45:31 +00:00
assert(uc2);
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
columns_align_next_to(cols, w, uc2->toplevel);
dialog system: add a side-by-side alignment feature. This will let us put two controls side by side (e.g. in disjoint columns of a multi-col layout) and indicate that instead of the default behaviour of aligning their top edges, their centreline (or, even better if available, font baseline) should be aligned. NFC: nothing uses this yet.
2021-04-03 16:45:31 +00:00
#if GTK_CHECK_VERSION(3, 10, 0)
/* Slightly nicer to align baselines than just vertically
* centring, where the option is available */
gtk_widget_set_valign(w, GTK_ALIGN_BASELINE);
gtk_widget_set_valign(uc2->toplevel, GTK_ALIGN_BASELINE);
#endif
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_show(w);
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc->toplevel = w;
dlg_add_uctrl(dp, uc);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
return ret;
}
struct selparam {
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
struct dlgparam *dp;
Colin Watson points out that there was no need for me to write the custom Panels container widget for the PuTTY config box, since the perfectly standard GtkNotebook does the same job. Hence, let's remove Panels completely in favour of doing it the proper way. [originally from svn r7034]
2006-12-29 14:35:34 +00:00
GtkNotebook *panels;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
GtkWidget *panel;
#if !GTK_CHECK_VERSION(2,0,0)
GtkWidget *treeitem;
Fix the jarring change of window size on expanding the SSH branch of the configuration tree. [originally from svn r7968]
2008-04-04 11:37:06 +00:00
#else
int depth;
GtkTreePath *treepath;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
struct Shortcuts shortcuts;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
};
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
static void treeselection_changed(GtkTreeSelection *treeselection,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gpointer data)
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
{
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
struct selparam **sps = (struct selparam **)data, *sp;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
GtkTreeModel *treemodel;
GtkTreeIter treeiter;
gint spindex;
gint page_num;
if (!gtk_tree_selection_get_selected(treeselection, &treemodel, &treeiter))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
gtk_tree_model_get(treemodel, &treeiter, TREESTORE_PARAMS, &spindex, -1);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
sp = sps[spindex];
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
page_num = gtk_notebook_page_num(sp->panels, sp->panel);
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
gtk_notebook_set_current_page(sp->panels, page_num);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
sp->dp->curr_panel = sp;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
dlg_refresh(NULL, sp->dp);
sp->dp->shortcuts = &sp->shortcuts;
}
#else
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void treeitem_sel(GtkItem *item, gpointer data)
{
struct selparam *sp = (struct selparam *)data;
Colin Watson points out that there was no need for me to write the custom Panels container widget for the PuTTY config box, since the perfectly standard GtkNotebook does the same job. Hence, let's remove Panels completely in favour of doing it the proper way. [originally from svn r7034]
2006-12-29 14:35:34 +00:00
gint page_num;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Colin Watson points out that there was no need for me to write the custom Panels container widget for the PuTTY config box, since the perfectly standard GtkNotebook does the same job. Hence, let's remove Panels completely in favour of doing it the proper way. [originally from svn r7034]
2006-12-29 14:35:34 +00:00
page_num = gtk_notebook_page_num(sp->panels, sp->panel);
gtk_notebook_set_page(sp->panels, page_num);
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
sp->dp->curr_panel = sp;
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
dlg_refresh(NULL, sp->dp);
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
sp->dp->shortcuts = &sp->shortcuts;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
sp->dp->currtreeitem = sp->treeitem;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
bool dlg_is_visible(dlgcontrol *ctrl, dlgparam *dp)
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
{
struct uctrl *uc = dlg_find_byctrl(dp, ctrl);
/*
* A control is visible if it belongs to _no_ notebook page (i.e.
* it's one of the config-box-global buttons like Load or About),
* or if it belongs to the currently selected page.
*/
return uc->sp == NULL || uc->sp == dp->curr_panel;
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool tree_grab_focus(struct dlgparam *dp)
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
{
int i, f;
/*
* See if any of the treeitems has the focus.
*/
f = -1;
for (i = 0; i < dp->ntreeitems; i++)
if (GTK_WIDGET_HAS_FOCUS(dp->treeitems[i])) {
f = i;
break;
}
if (f >= 0)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
else {
gtk_widget_grab_focus(dp->currtreeitem);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
}
}
gint tree_focus(GtkContainer *container, GtkDirectionType direction,
gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_stop_emission_by_name(G_OBJECT(container), "focus");
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
/*
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
* If there's a focused treeitem, we return false to cause the
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
* focus to move on to some totally other control. If not, we
* focus the selected one.
*/
return tree_grab_focus(dp);
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
gint win_key_press(GtkWidget *widget, GdkEventKey *event, gpointer data)
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
if (event->keyval == GDK_KEY_Escape && dp->cancelbutton) {
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_emit_by_name(G_OBJECT(dp->cancelbutton), "clicked");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return true;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
if ((event->state & GDK_MOD1_MASK) &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(unsigned char)event->string[0] > 0 &&
(unsigned char)event->string[0] <= 127) {
int schr = (unsigned char)event->string[0];
struct Shortcut *sc = &dp->shortcuts->sc[schr];
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
switch (sc->action) {
case SHORTCUT_TREE:
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_grab_focus(sc->widget);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
tree_grab_focus(dp);
#endif
break;
case SHORTCUT_FOCUS:
gtk_widget_grab_focus(sc->widget);
break;
case SHORTCUT_UCTRL:
/*
* We must do something sensible with a uctrl.
* Precisely what this is depends on the type of
* control.
*/
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
switch (sc->uc->ctrl->type) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case CTRL_CHECKBOX:
case CTRL_BUTTON:
/* Check boxes and buttons get the focus _and_ get toggled. */
gtk_widget_grab_focus(sc->uc->toplevel);
g_signal_emit_by_name(G_OBJECT(sc->uc->toplevel), "clicked");
break;
case CTRL_FILESELECT:
case CTRL_FONTSELECT:
/* File/font selectors have their buttons pressed (ooer),
* and focus transferred to the edit box. */
g_signal_emit_by_name(G_OBJECT(sc->uc->button), "clicked");
Permit button-only file selectors. Instead of an edit box together with a Browse button that pops up a sub-dialog, this is _just_ the browse button, only now it has a user-defined title. I'm about to want to use this for loading CA public keys from files.
2022-05-01 07:39:49 +00:00
if (sc->uc->entry)
gtk_widget_grab_focus(sc->uc->entry);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
case CTRL_RADIO:
/*
* Radio buttons are fun, because they have
* multiple shortcuts. We must find whether the
* activated shortcut is the shortcut for the whole
* group, or for a particular button. In the former
* case, we find the currently selected button and
* focus it; in the latter, we focus-and-click the
* button whose shortcut was pressed.
*/
if (schr == sc->uc->ctrl->radio.shortcut) {
int i;
for (i = 0; i < sc->uc->ctrl->radio.nbuttons; i++)
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
if (gtk_toggle_button_get_active(
GTK_TOGGLE_BUTTON(sc->uc->buttons[i]))) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_grab_focus(sc->uc->buttons[i]);
}
} else if (sc->uc->ctrl->radio.shortcuts) {
int i;
for (i = 0; i < sc->uc->ctrl->radio.nbuttons; i++)
if (schr == sc->uc->ctrl->radio.shortcuts[i]) {
gtk_widget_grab_focus(sc->uc->buttons[i]);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
g_signal_emit_by_name(
G_OBJECT(sc->uc->buttons[i]), "clicked");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
break;
case CTRL_LISTBOX:
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#if !GTK_CHECK_VERSION(2,4,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (sc->uc->optmenu) {
GdkEventButton bev;
gint returnval;
gtk_widget_grab_focus(sc->uc->optmenu);
/* Option menus don't work using the "clicked" signal.
* We need to manufacture a button press event :-/ */
bev.type = GDK_BUTTON_PRESS;
bev.button = 1;
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_emit_by_name(G_OBJECT(sc->uc->optmenu),
"button_press_event",
&bev, &returnval);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (sc->uc->combo) {
gtk_widget_grab_focus(sc->uc->combo);
gtk_combo_box_popup(GTK_COMBO_BOX(sc->uc->combo));
break;
}
Re-jig the combo box handling ifdefs so that we can compile with GTK versions >= 2.0 (when the new list boxes came in) but < 2.4 (when the new combo boxes came in). Since some combo boxes are handled using the old list-box code, this means that the two lots of code can both be compiled in at once in some situations! [originally from svn r8031]
2008-05-31 19:23:45 +00:00
#endif
#if !GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (sc->uc->list) {
/*
* For GTK-1 style list boxes, we tell it to
* focus one of its children, which appears to
* do the Right Thing.
*/
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
gtk_container_focus(GTK_CONTAINER(sc->uc->list),
GTK_DIR_TAB_FORWARD);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (sc->uc->treeview) {
gtk_widget_grab_focus(sc->uc->treeview);
break;
}
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Convert a few more universal asserts to unreachable(). When I introduced the unreachable() macro in commit 0112936ef, I searched the source code for assert(0) and assert(false), together with their variant form assert(0 && "explanatory text"). But I didn't search for assert(!"explanatory text"), which is the form I used to use before finding that assert(0 && "text") seemed to be preferred in other code bases. So, here's a belated replacement of all the assert(!"stuff") macros with further instances of unreachable().
2019-09-09 18:07:55 +00:00
unreachable("bad listbox type in win_key_press");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
break;
}
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
gint tree_key_press(GtkWidget *widget, GdkEventKey *event, gpointer data)
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
{
struct dlgparam *dp = (struct dlgparam *)data;
if (event->keyval == GDK_Up || event->keyval == GDK_KP_Up ||
event->keyval == GDK_Down || event->keyval == GDK_KP_Down) {
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
int dir, i, j = -1;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
for (i = 0; i < dp->ntreeitems; i++)
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
if (widget == dp->treeitems[i])
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
if (i < dp->ntreeitems) {
if (event->keyval == GDK_Up || event->keyval == GDK_KP_Up)
dir = -1;
else
dir = +1;
while (1) {
i += dir;
if (i < 0 || i >= dp->ntreeitems)
break; /* nothing in that dir to select */
/*
* Determine if this tree item is visible.
*/
{
GtkWidget *w = dp->treeitems[i];
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool vis = true;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while (w && (GTK_IS_TREE_ITEM(w) || GTK_IS_TREE(w))) {
if (!GTK_WIDGET_VISIBLE(w)) {
vis = false;
break;
}
w = w->parent;
}
if (vis) {
j = i; /* got one */
break;
}
}
}
}
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_stop_emission_by_name(G_OBJECT(widget), "key_press_event");
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
if (j >= 0) {
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_emit_by_name(G_OBJECT(dp->treeitems[j]), "toggle");
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
gtk_widget_grab_focus(dp->treeitems[j]);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
}
/*
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
* It's nice for Left and Right to expand and collapse tree
* branches.
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
*/
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
if (event->keyval == GDK_Left || event->keyval == GDK_KP_Left) {
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_stop_emission_by_name(G_OBJECT(widget), "key_press_event");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_tree_item_collapse(GTK_TREE_ITEM(widget));
return true;
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
}
if (event->keyval == GDK_Right || event->keyval == GDK_KP_Right) {
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_stop_emission_by_name(G_OBJECT(widget), "key_press_event");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_tree_item_expand(GTK_TREE_ITEM(widget));
return true;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
}
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
static void shortcut_highlight(GtkWidget *labelw, int chr)
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
{
GtkLabel *label = GTK_LABEL(labelw);
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
const gchar *currstr;
gchar *pattern;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
int i;
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
{
gchar *currstr_nonconst;
gtk_label_get(label, &currstr_nonconst);
currstr = currstr_nonconst;
}
#else
currstr = gtk_label_get_text(label);
#endif
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
for (i = 0; currstr[i]; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (tolower((unsigned char)currstr[i]) == chr) {
pattern = dupprintf("%*s_", i, "");
gtk_label_set_pattern(label, pattern);
sfree(pattern);
break;
}
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
}
void shortcut_add(struct Shortcuts *scs, GtkWidget *labelw,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int chr, int action, void *ptr)
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
{
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
if (chr == NO_SHORTCUT)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
chr = tolower((unsigned char)chr);
assert(scs->sc[chr].action == SHORTCUT_EMPTY);
scs->sc[chr].action = action;
Permit the config box treeview to be keyboard-selected. I'd failed to set the widget field in its shortcut structure, leading to an annoying GTK warning log message and no useful UI action when Alt-G was pressed in the config box.
2015-09-26 12:12:25 +00:00
if (action == SHORTCUT_FOCUS || action == SHORTCUT_TREE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
scs->sc[chr].uc = NULL;
scs->sc[chr].widget = (GtkWidget *)ptr;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
scs->sc[chr].widget = NULL;
scs->sc[chr].uc = (struct uctrl *)ptr;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. [originally from svn r6822]
2006-08-28 14:29:02 +00:00
shortcut_highlight(labelw, chr);
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
Add missing 'static' on file-internal declarations. sk_startup and sk_nextaddr are entirely internal to winnet.c; nearly all of import.c and minibidi.c's internal routines should have been static and weren't; {read,write}_utf8 are internal to charset/utf8.c (and didn't even need separate declarations at all); do_sftp_cleanup is internal to psftp.c, and get_listitemheight to gtkdlg.c. While I was editing those prototypes anyway, I've also added missing 'const' to the 'char *' passphrase parameters in import,c.
2018-11-03 08:25:28 +00:00
static int get_listitemheight(GtkWidget *w)
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
{
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
GtkWidget *listitem = gtk_list_item_new_with_label("foo");
GtkRequisition req;
gtk_widget_size_request(listitem, &req);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_ref_sink(G_OBJECT(listitem));
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
return req.height;
#else
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
int height;
GtkCellRenderer *cr = gtk_cell_renderer_text_new();
Avoid deprecated gtk_cell_renderer_get_size in GTK3. gtk_cell_renderer_get_preferred_size() is the new way to do it.
2015-08-22 12:53:29 +00:00
#if GTK_CHECK_VERSION(3,0,0)
{
GtkRequisition req;
/*
* Since none of my list items wraps in this GUI, no
* interesting width-for-height behaviour should be happening,
* so I don't think it should matter here whether I ask for
* the minimum or natural height.
*/
gtk_cell_renderer_get_preferred_size(cr, w, &req, NULL);
height = req.height;
}
#else
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
gtk_cell_renderer_get_size(cr, w, NULL, NULL, NULL, NULL, &height);
Avoid deprecated gtk_cell_renderer_get_size in GTK3. gtk_cell_renderer_get_preferred_size() is the new way to do it.
2015-08-22 12:53:29 +00:00
#endif
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
g_object_ref(G_OBJECT(cr));
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_object_ref_sink(G_OBJECT(cr));
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
g_object_unref(G_OBJECT(cr));
return height;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
#if GTK_CHECK_VERSION(2,0,0)
void initial_treeview_collapse(struct dlgparam *dp, GtkWidget *tree)
{
/*
* Collapse the deeper branches of the treeview into the state we
* like them to start off in. See comment below in do_config_box.
*/
int i;
for (i = 0; i < dp->nselparams; i++)
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
if (dp->selparams[i]->depth >= 2)
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
gtk_tree_view_collapse_row(GTK_TREE_VIEW(tree),
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
dp->selparams[i]->treepath);
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
}
#endif
#if GTK_CHECK_VERSION(3,0,0)
void treeview_map_event(GtkWidget *tree, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
GtkAllocation alloc;
gtk_widget_get_allocation(tree, &alloc);
gtk_widget_set_size_request(tree, alloc.width, -1);
initial_treeview_collapse(dp, tree);
}
#endif
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
GtkWidget *create_config_box(const char *title, Conf *conf,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool midsession, int protcfginfo,
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
post_dialog_fn_t after, void *afterctx)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
GtkWidget *window, *hbox, *vbox, *cols, *label,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*tree, *treescroll, *panels, *panelvbox;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int index, level, protocol;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
char *path;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
GtkTreeStore *treestore;
GtkCellRenderer *treerenderer;
GtkTreeViewColumn *treecolumn;
GtkTreeSelection *treeselection;
GtkTreeIter treeiterlevels[8];
#else
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
GtkTreeItem *treeitemlevels[8];
GtkTree *treelevels[8];
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
struct dlgparam *dp;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
struct Shortcuts scs;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
struct selparam **selparams = NULL;
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
size_t nselparams = 0, selparamsize = 0;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dp = snew(struct dlgparam);
dp->after = after;
dp->afterctx = afterctx;
dlg_init(dp);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
for (index = 0; index < lenof(scs.sc); index++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
scs.sc[index].action = SHORTCUT_EMPTY;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
}
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
window = our_dialog_new();
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dp->ctrlbox = ctrl_new_box();
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
protocol = conf_get_int(conf, CONF_protocol);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
setup_config_box(dp->ctrlbox, midsession, protocol, protcfginfo);
unix_setup_config_box(dp->ctrlbox, midsession, protocol);
gtk_setup_config_box(dp->ctrlbox, midsession, window);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
gtk_window_set_title(GTK_WINDOW(window), title);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
hbox = gtk_hbox_new(false, 4);
our_dialog_add_to_content_area(GTK_WINDOW(window), hbox, true, true, 0);
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
gtk_container_set_border_width(GTK_CONTAINER(hbox), 10);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_show(hbox);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
vbox = gtk_vbox_new(false, 4);
gtk_box_pack_start(GTK_BOX(hbox), vbox, false, false, 0);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_show(vbox);
cols = columns_new(4);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_box_pack_start(GTK_BOX(vbox), cols, false, false, 0);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_show(cols);
label = gtk_label_new("Category:");
columns_add(COLUMNS(cols), label, 0, 1);
columns_force_left_align(COLUMNS(cols), label);
gtk_widget_show(label);
treescroll = gtk_scrolled_window_new(NULL, NULL);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
treestore = gtk_tree_store_new(
TREESTORE_NUM, G_TYPE_STRING, G_TYPE_INT);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
tree = gtk_tree_view_new_with_model(GTK_TREE_MODEL(treestore));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(tree), false);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
treerenderer = gtk_cell_renderer_text_new();
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
treecolumn = gtk_tree_view_column_new_with_attributes(
"Label", treerenderer, "text", 0, NULL);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
gtk_tree_view_append_column(GTK_TREE_VIEW(tree), treecolumn);
treeselection = gtk_tree_view_get_selection(GTK_TREE_VIEW(tree));
gtk_tree_selection_set_mode(treeselection, GTK_SELECTION_BROWSE);
gtk_container_add(GTK_CONTAINER(treescroll), tree);
#else
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
tree = gtk_tree_new();
gtk_tree_set_view_mode(GTK_TREE(tree), GTK_TREE_VIEW_ITEM);
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
gtk_tree_set_selection_mode(GTK_TREE(tree), GTK_SELECTION_BROWSE);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
g_signal_connect(G_OBJECT(tree), "focus", G_CALLBACK(tree_focus), dp);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(tree), "focus_in_event",
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
G_CALLBACK(widget_focus), dp);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
shortcut_add(&scs, label, 'g', SHORTCUT_TREE, tree);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_show(treescroll);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_box_pack_start(GTK_BOX(vbox), treescroll, true, true, 0);
Colin Watson points out that there was no need for me to write the custom Panels container widget for the PuTTY config box, since the perfectly standard GtkNotebook does the same job. Hence, let's remove Panels completely in favour of doing it the proper way. [originally from svn r7034]
2006-12-29 14:35:34 +00:00
panels = gtk_notebook_new();
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_notebook_set_show_tabs(GTK_NOTEBOOK(panels), false);
gtk_notebook_set_show_border(GTK_NOTEBOOK(panels), false);
gtk_box_pack_start(GTK_BOX(hbox), panels, true, true, 0);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_show(panels);
panelvbox = NULL;
path = NULL;
level = 0;
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
for (index = 0; index < dp->ctrlbox->nctrlsets; index++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct controlset *s = dp->ctrlbox->ctrlsets[index];
GtkWidget *w;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!*s->pathname) {
w = layout_ctrls(dp, NULL, &scs, s, GTK_WINDOW(window));
Fix the incorrect layout of the buttons at the bottom of the main config box. [originally from svn r7160]
2007-01-25 19:45:50 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
our_dialog_set_action_area(GTK_WINDOW(window), w);
} else {
int j = path ? ctrl_path_compare(s->pathname, path) : 0;
if (j != INT_MAX) { /* add to treeview, start new panel */
char *c;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkTreeIter treeiter;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkWidget *treeitem;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bool first;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* We expect never to find an implicit path
* component. For example, we expect never to see
* A/B/C followed by A/D/E, because that would
* _implicitly_ create A/D. All our path prefixes
* are expected to contain actual controls and be
* selectable in the treeview; so we would expect
* to see A/D _explicitly_ before encountering
* A/D/E.
*/
assert(j == ctrl_path_elements(s->pathname) - 1);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
c = strrchr(s->pathname, '/');
if (!c)
c = s->pathname;
else
c++;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
path = s->pathname;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
first = (panelvbox == NULL);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
panelvbox = gtk_vbox_new(false, 4);
gtk_widget_show(panelvbox);
gtk_notebook_append_page(GTK_NOTEBOOK(panels), panelvbox,
NULL);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
struct selparam *sp = snew(struct selparam);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (first) {
gint page_num;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
page_num = gtk_notebook_page_num(GTK_NOTEBOOK(panels),
panelvbox);
gtk_notebook_set_current_page(GTK_NOTEBOOK(panels),
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
page_num);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
dp->curr_panel = sp;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
sgrowarray(selparams, selparamsize, nselparams);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
selparams[nselparams] = sp;
sp->dp = dp;
sp->panels = GTK_NOTEBOOK(panels);
sp->panel = panelvbox;
sp->shortcuts = scs; /* structure copy */
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(j-1 < level);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (j > 0)
/* treeiterlevels[j-1] will always be valid because we
* don't allow implicit path components; see above.
*/
gtk_tree_store_append(treestore, &treeiter,
&treeiterlevels[j-1]);
else
gtk_tree_store_append(treestore, &treeiter, NULL);
gtk_tree_store_set(treestore, &treeiter,
TREESTORE_PATH, c,
TREESTORE_PARAMS, nselparams,
-1);
treeiterlevels[j] = treeiter;
sp->depth = j;
if (j > 0) {
sp->treepath = gtk_tree_model_get_path(
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
GTK_TREE_MODEL(treestore), &treeiterlevels[j-1]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* We are going to collapse all tree branches
* at depth greater than 2, but not _yet_; see
* the comment at the call to
* gtk_tree_view_collapse_row below.
*/
gtk_tree_view_expand_row(GTK_TREE_VIEW(tree),
sp->treepath, false);
} else {
sp->treepath = NULL;
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
treeitem = gtk_tree_item_new_with_label(c);
if (j > 0) {
if (!treelevels[j-1]) {
treelevels[j-1] = GTK_TREE(gtk_tree_new());
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_tree_item_set_subtree(
treeitemlevels[j-1], GTK_WIDGET(treelevels[j-1]));
Fold up the `SSH' branch of the treeview by default; it's getting quite big and tends to hide the existence of the `Serial' config panel. This is implemented by folding up every branch of depth 2 or more, which with any luck might turn out to be general enough to carry over unchanged if other branches start expanding. Then again, we may have to fiddle with it again when that time comes; who knows? [originally from svn r7117]
2007-01-16 18:48:47 +00:00
if (j < 2)
gtk_tree_item_expand(treeitemlevels[j-1]);
else
gtk_tree_item_collapse(treeitemlevels[j-1]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
gtk_tree_append(treelevels[j-1], treeitem);
} else {
gtk_tree_append(GTK_TREE(tree), treeitem);
}
treeitemlevels[j] = GTK_TREE_ITEM(treeitem);
treelevels[j] = NULL;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(treeitem), "key_press_event",
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
G_CALLBACK(tree_key_press), dp);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(treeitem), "focus_in_event",
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
G_CALLBACK(widget_focus), dp);
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_show(treeitem);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (first)
gtk_tree_select_child(GTK_TREE(tree), treeitem);
sp->treeitem = treeitem;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
level = j+1;
nselparams++;
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
w = layout_ctrls(dp, selparams[nselparams-1],
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
&selparams[nselparams-1]->shortcuts, s, NULL);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_box_pack_start(GTK_BOX(panelvbox), w, false, false, 0);
Continuing work on the GTK config box. Created uxcfg.c for the Unix-specific config items; moved a stray Windows-specific config item (scrollbar-in-fullscreen) out into wincfg.c to stop it appearing on Unix; continued updates to gtkdlg.c. I now believe the GTK config box looks basically correct (modulo minor cosmetic issues and keyboard accelerators). Next step, add the event handling so it's actually functional. [originally from svn r2933]
2003-03-14 18:35:01 +00:00
gtk_widget_show(w);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Fix the jarring change of window size on expanding the SSH branch of the configuration tree. [originally from svn r7968]
2008-04-04 11:37:06 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
/*
* We want our tree view to come up with all branches at depth 2
* or more collapsed. However, if we start off with those branches
* collapsed, then the tree view's size request will be calculated
* based on the width of the collapsed tree, and then when the
* collapsed branches are expanded later, the tree view will
* jarringly change size.
*
* So instead we start with everything expanded; then, once the
* tree view has computed its resulting width requirement, we
* collapse the relevant rows, but force the width to be the value
* we just retrieved. This arranges that the tree view is wide
* enough to have all branches expanded without further resizing.
*/
Fix the jarring change of window size on expanding the SSH branch of the configuration tree. [originally from svn r7968]
2008-04-04 11:37:06 +00:00
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dp->nselparams = nselparams;
dp->selparams = selparams;
Fix the jarring change of window size on expanding the SSH branch of the configuration tree. [originally from svn r7968]
2008-04-04 11:37:06 +00:00
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
{
/*
* In GTK2, we can just do the job right now.
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkRequisition req;
gtk_widget_size_request(tree, &req);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
initial_treeview_collapse(dp, tree);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_set_size_request(tree, req.width, -1);
Fix the jarring change of window size on expanding the SSH branch of the configuration tree. [originally from svn r7968]
2008-04-04 11:37:06 +00:00
}
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
#else
/*
* But in GTK3, we have to wait until the widget is about to be
* mapped, because the size computation won't have been done yet.
*/
g_signal_connect(G_OBJECT(tree), "map",
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
G_CALLBACK(treeview_map_event), dp);
Fix the config box treeview width in GTK3. My trickery in GTK2 to start with some branches of the tree collapsed but give the widget all the width it will need when they open later was not working in GTK3, for the same reason I've needed several other fixes recently: just after creation, GTK3 widgets report their preferred size as zero. Fixed by doing basically the same trick I was doing in GTK2, but deferring it until the "map" event happens later on.
2015-08-25 18:44:44 +00:00
#endif /* GTK 2 vs 3 */
#endif /* GTK 2+ vs 1 */
Fix the jarring change of window size on expanding the SSH branch of the configuration tree. [originally from svn r7968]
2008-04-04 11:37:06 +00:00
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if GTK_CHECK_VERSION(2,0,0)
g_signal_connect(G_OBJECT(treeselection), "changed",
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
G_CALLBACK(treeselection_changed), selparams);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#else
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dp->ntreeitems = nselparams;
dp->treeitems = snewn(dp->ntreeitems, GtkWidget *);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
for (index = 0; index < nselparams; index++) {
Fix build failure on GTK 1. This should have been part of commit e790adec4, but wasn't.
2019-10-15 19:11:30 +00:00
g_signal_connect(G_OBJECT(selparams[index]->treeitem), "select",
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
G_CALLBACK(treeitem_sel),
Fix config-panel switching on GTK 1. When I reworked the 'selparams' array in commit e790adec4 to contain pointers to 'struct selparam' rather than directly containing structures, I missed this one case where I should have removed an &. As a result the GTK1 signal handler that deals with clicks on the config-pane selection treeview was getting a pointer to a pointer and treating it as a pointer to an object. Nothing good happened.
2019-11-02 08:37:30 +00:00
selparams[index]);
Fix build failure on GTK 1. This should have been part of commit e790adec4, but wasn't.
2019-10-15 19:11:30 +00:00
dp->treeitems[index] = selparams[index]->treeitem;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dp->data = conf;
dlg_refresh(NULL, dp);
Event handling in the GTK dialog engine is now basically present and correct. All the callbacks are getting called, all the dialog actions are working (the port forwarding, colour and charclass configurers are all completely functional), file, font and colour selectors happen, and it's all looking pretty cool. [originally from svn r2938]
2003-03-15 15:50:42 +00:00
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
dp->shortcuts = &selparams[0]->shortcuts;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dp->currtreeitem = dp->treeitems[0];
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dp->lastfocus = NULL;
dp->retval = -1;
dp->window = window;
Further work on the GTK config box; mostly implemented keyboard shortcuts now (only treeviews and list boxes to go, which currently do very weird things and I need to overhaul them completely). [originally from svn r2944]
2003-03-16 12:37:48 +00:00
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
set_window_icon(window, cfg_icon, n_cfg_icon);
No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh. [originally from svn r7064]
2007-01-06 18:27:00 +00:00
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Fold up the `SSH' branch of the treeview by default; it's getting quite big and tends to hide the existence of the `Serial' config panel. This is implemented by folding up every branch of depth 2 or more, which with any luck might turn out to be general enough to carry over unchanged if other branches start expanding. Then again, we may have to fiddle with it again when that time comes; who knows? [originally from svn r7117]
2007-01-16 18:48:47 +00:00
gtk_scrolled_window_add_with_viewport(GTK_SCROLLED_WINDOW(treescroll),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
tree);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
Fold up the `SSH' branch of the treeview by default; it's getting quite big and tends to hide the existence of the `Serial' config panel. This is implemented by folding up every branch of depth 2 or more, which with any luck might turn out to be general enough to carry over unchanged if other branches start expanding. Then again, we may have to fiddle with it again when that time comes; who knows? [originally from svn r7117]
2007-01-16 18:48:47 +00:00
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(treescroll),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GTK_POLICY_NEVER,
GTK_POLICY_AUTOMATIC);
Fold up the `SSH' branch of the treeview by default; it's getting quite big and tends to hide the existence of the `Serial' config panel. This is implemented by folding up every branch of depth 2 or more, which with any luck might turn out to be general enough to carry over unchanged if other branches start expanding. Then again, we may have to fiddle with it again when that time comes; who knows? [originally from svn r7117]
2007-01-16 18:48:47 +00:00
gtk_widget_show(tree);
Better appearance and positioning for dlg_error_msg box, and also I've just found out that it's easy to ask for the config box to be centred on the screen by default, which is kinda cool. [originally from svn r2962]
2003-03-18 19:47:28 +00:00
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_show(window);
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
/*
* Set focus into the first available control.
*/
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
for (index = 0; index < dp->ctrlbox->nctrlsets; index++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct controlset *s = dp->ctrlbox->ctrlsets[index];
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool done = false;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
int j;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (*s->pathname) {
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
for (j = 0; j < s->ncontrols; j++)
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (s->ctrls[j]->type != CTRL_TABDELAY &&
s->ctrls[j]->type != CTRL_COLUMNS &&
s->ctrls[j]->type != CTRL_TEXT) {
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dlg_set_focus(s->ctrls[j], dp);
dp->lastfocus = s->ctrls[j];
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
done = true;
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
break;
}
}
if (done)
break;
}
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(window), "destroy",
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
G_CALLBACK(dlgparam_destroy), dp);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(window), "key_press_event",
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
G_CALLBACK(win_key_press), dp);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
return window;
}
Big sprawling dialog-box commit covering all sorts of things. Buttons now have an `iscancel' flag to go with `isdefault'; dlg_last_focused() now explicitly passes the control it _doesn't_ care about (`I want the last control that had focus and isn't this one'); and in the GTK implementation, various fixes have happened, notably including arrow keys working sensibly in list boxes and the treeview and short font aliases being expanded correctly to initialise the font selectors. [originally from svn r2958]
2003-03-18 19:06:51 +00:00
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
static void dlgparam_destroy(GtkWidget *widget, gpointer data)
{
struct dlgparam *dp = (struct dlgparam *)data;
Fix a cleanup issue in dlgparam_destroy. If a dialog box is destroyed by the program before the user has pressed one of the result-delivering buttons - e.g. because the parent window closes so the dialog is no longer relevant to anything anyway - then dlgparam_destroy would never call the client code's provided callback. That makes sense in terms of the callback wanting to _take action_ based on the result of the dialog box, but it ignores the possibility that the callback may simply need to free its own context structure. So now dlgparam_destroy always calls the client's callback, even if the result it passes is negative (meaning 'the user never got round to pressing any of the dialog-ending buttons'), and all the existing client callbacks handle the negative-result case by doing nothing except freeing any allocated memory they might have.
2017-11-26 14:37:38 +00:00
dp->after(dp->afterctx, dp->retval);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
dlg_cleanup(dp);
ctrl_free_box(dp->ctrlbox);
#if GTK_CHECK_VERSION(2,0,0)
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
if (dp->selparams) {
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
for (size_t i = 0; i < dp->nselparams; i++) {
if (dp->selparams[i]->treepath)
gtk_tree_path_free(dp->selparams[i]->treepath);
sfree(dp->selparams[i]);
}
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
sfree(dp->selparams);
Make the configuration dialog non-modal. Now every call to do_config_box is replaced with a call to create_config_box, which returns immediately having constructed the new GTK window object, and is passed a callback function which it will arrange to be called when the dialog terminates (whether by OK or by Cancel). That callback is now what triggers the construction of a session window after 'Open' is pressed in the initial config box, or the actual mid-session reconfiguration action after 'Apply' is pressed in a Change Settings box. We were already prepared to ignore the re-selection of 'Change Settings' from the context menu of a window that already had a Change Settings box open (and not accidentally create a second config box for the same window); but now we do slightly better, by finding the existing config box and un-minimising and raising it, in case the user had forgotten it was there. That's a useful featurelet, but not the main purpose of this change. The mani point, of course, is that now the multi-window GtkApplication based front ends now don't do anything confusing to the nesting of gtk_main() when config boxes are involved. Whether you're changing the settings of one (or more than one) of your already-running sessions, preparing to start up a new PuTTY connection, or both at once, we stay in the same top-level instance of gtk_main() and all sessions' top- level callbacks continue to run sensibly.
2017-11-26 11:58:02 +00:00
}
#endif
sfree(dp);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
static void messagebox_handler(dlgcontrol *ctrl, dlgparam *dp,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *data, int event)
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
{
if (event == EVENT_ACTION)
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
dlg_end(dp, ctrl->context.i);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
}
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
Add lots of missing 'static' keywords. A trawl through the code with -Wmissing-prototypes and -Wmissing-variable-declarations turned up a lot of things that should have been internal to a particular source file, but were accidentally global. Keep the namespace clean by making them all static. (Also, while I'm here, a couple of them were missing a 'const': the ONE and ZERO arrays in sshcrcda.c, and EMPTY_WINDOW_TITLE in terminal.c.)
2020-01-29 06:22:01 +00:00
static const struct message_box_button button_array_yn[] = {
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
{"Yes", 'y', +1, 1},
{"No", 'n', -1, 0},
};
const struct message_box_buttons buttons_yn = {
button_array_yn, lenof(button_array_yn),
};
Add lots of missing 'static' keywords. A trawl through the code with -Wmissing-prototypes and -Wmissing-variable-declarations turned up a lot of things that should have been internal to a particular source file, but were accidentally global. Keep the namespace clean by making them all static. (Also, while I'm here, a couple of them were missing a 'const': the ONE and ZERO arrays in sshcrcda.c, and EMPTY_WINDOW_TITLE in terminal.c.)
2020-01-29 06:22:01 +00:00
static const struct message_box_button button_array_ok[] = {
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
{"OK", 'o', 1, 1},
};
const struct message_box_buttons buttons_ok = {
button_array_ok, lenof(button_array_ok),
};
GTK: add a callback to create_message_box. This lets the caller of create_message_box modify the dialog in small ways without having to repeat all the rest of the hard work as well.
2021-03-13 11:05:39 +00:00
static GtkWidget *create_message_box_general(
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
GtkWidget *parentwin, const char *title, const char *msg, int minwid,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool selectable, const struct message_box_buttons *buttons,
GTK: add a callback to create_message_box. This lets the caller of create_message_box modify the dialog in small ways without having to repeat all the rest of the hard work as well.
2021-03-13 11:05:39 +00:00
post_dialog_fn_t after, void *afterctx,
GtkWidget *(*action_postproc)(GtkWidget *, void *), void *postproc_ctx)
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
{
GtkWidget *window, *w0, *w1;
struct controlset *s0, *s1;
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *c, *textctrl;
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
struct dlgparam *dp;
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
struct Shortcuts scs;
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
int i, index, ncols, min_type;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
dp = snew(struct dlgparam);
dp->after = after;
dp->afterctx = afterctx;
dlg_init(dp);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
for (index = 0; index < lenof(scs.sc); index++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
scs.sc[index].action = SHORTCUT_EMPTY;
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
dp->ctrlbox = ctrl_new_box();
Various cosmetic fixes to the GTK config box: vertical alignment of edit box labels, Left/Right on the treeview to collapse and expand branches, a window title, and the best treatment of wrapping text widgets I could think of within the product-order-oriented GTK layout model. I think this thing is now pretty much as good as it's going to get before GTK v2 (which should fix one or two remaining minor nasties which I really couldn't be bothered to work around in GTK 1.2), so the next step is to actually start _using_ it. [originally from svn r2979]
2003-03-22 17:00:06 +00:00
Make sure Escape in a message box always does something. The askalg() dialog, and several one-button things like the licence box, have no button labelled 'cancel'. But in all cases we do want Escape to terminate the box, with as negative an answer as is available. So now we assign the 'iscancel' flag to any button whose numeric value is the smallest of the ones given as input to messagebox(). (In a one-button box, this leads to isdefault and iscancel _both_ being set for that button. That's fine; it works.)
2015-09-26 12:57:12 +00:00
/*
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
* Count up the number of buttons and find out what kinds there
* are.
Make sure Escape in a message box always does something. The askalg() dialog, and several one-button things like the licence box, have no button labelled 'cancel'. But in all cases we do want Escape to terminate the box, with as negative an answer as is available. So now we assign the 'iscancel' flag to any button whose numeric value is the smallest of the ones given as input to messagebox(). (In a one-button box, this leads to isdefault and iscancel _both_ being set for that button. That's fine; it works.)
2015-09-26 12:57:12 +00:00
*/
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
ncols = 0;
Make sure Escape in a message box always does something. The askalg() dialog, and several one-button things like the licence box, have no button labelled 'cancel'. But in all cases we do want Escape to terminate the box, with as negative an answer as is available. So now we assign the 'iscancel' flag to any button whose numeric value is the smallest of the ones given as input to messagebox(). (In a one-button box, this leads to isdefault and iscancel _both_ being set for that button. That's fine; it works.)
2015-09-26 12:57:12 +00:00
min_type = +1;
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
for (i = 0; i < buttons->nbuttons; i++) {
const struct message_box_button *button = &buttons->buttons[i];
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ncols++;
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
if (min_type > button->type)
min_type = button->type;
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
assert(button->value >= 0); /* <0 means no return value available */
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
s0 = ctrl_getset(dp->ctrlbox, "", "", "");
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
c = ctrl_columns(s0, 2, 50, 50);
c->columns.ncols = s0->ncolumns = ncols;
c->columns.percentages = sresize(c->columns.percentages, ncols, int);
for (index = 0; index < ncols; index++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
c->columns.percentages[index] = (index+1)*100/ncols - index*100/ncols;
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
index = 0;
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
for (i = 0; i < buttons->nbuttons; i++) {
const struct message_box_button *button = &buttons->buttons[i];
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
c = ctrl_pushbutton(s0, button->title, button->shortcut,
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
HELPCTX(no_help), messagebox_handler,
I(button->value));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
c->column = index++;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (button->type > 0)
c->button.isdefault = true;
Make sure Escape in a message box always does something. The askalg() dialog, and several one-button things like the licence box, have no button labelled 'cancel'. But in all cases we do want Escape to terminate the box, with as negative an answer as is available. So now we assign the 'iscancel' flag to any button whose numeric value is the smallest of the ones given as input to messagebox(). (In a one-button box, this leads to isdefault and iscancel _both_ being set for that button. That's fine; it works.)
2015-09-26 12:57:12 +00:00
/* We always arrange that _some_ button is labelled as
* 'iscancel', so that pressing Escape will always cause
* win_key_press to do something. The button we choose is
* whichever has the smallest type value: this means that real
* cancel buttons (labelled -1) will be picked if one is
* there, or in cases where the options are yes/no (1,0) then
* no will be picked, and if there's only one option (a box
* that really is just showing a _message_ and not even asking
* a question) then that will be picked. */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (button->type == min_type)
c->button.iscancel = true;
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
s1 = ctrl_getset(dp->ctrlbox, "x", "", "");
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 12:32:48 +00:00
textctrl = ctrl_text(s1, msg, HELPCTX(no_help));
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
window = our_dialog_new();
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
gtk_window_set_title(GTK_WINDOW(window), title);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
w0 = layout_ctrls(dp, NULL, &scs, s0, GTK_WINDOW(window));
GTK: add a callback to create_message_box. This lets the caller of create_message_box modify the dialog in small ways without having to repeat all the rest of the hard work as well.
2021-03-13 11:05:39 +00:00
if (action_postproc)
w0 = action_postproc(w0, postproc_ctx);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
our_dialog_set_action_area(GTK_WINDOW(window), w0);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
gtk_widget_show(w0);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
w1 = layout_ctrls(dp, NULL, &scs, s1, GTK_WINDOW(window));
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
gtk_container_set_border_width(GTK_CONTAINER(w1), 10);
GTK 3 prep: stop using *nearly* all GTK deprecated functions. Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile failure, for the use of gtk_quit_add() in idle_toplevel_callback_func. That function is apparently removed with no replacement in GTK 3, so I'll need to find a completely different approach to getting toplevel callbacks to run only in the outermost instance of gtk_main(). Also, this change doesn't do anything about the use of *GDK* deprecated functions, because those include the entire family of old-style drawing functions - i.e. the only way to build cleanly with -DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.
2015-08-08 17:02:01 +00:00
gtk_widget_set_size_request(w1, minwid+20, -1);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
our_dialog_add_to_content_area(GTK_WINDOW(window), w1, true, true, 0);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
gtk_widget_show(w1);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
dp->shortcuts = &scs;
dp->lastfocus = NULL;
dp->retval = 0;
dp->window = window;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
if (parentwin) {
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
set_transient_window_pos(parentwin, window);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_set_transient_for(GTK_WINDOW(window),
GTK_WINDOW(parentwin));
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
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 12:32:48 +00:00
gtk_container_set_focus_child(GTK_CONTAINER(window), NULL);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
gtk_widget_show(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 12:32:48 +00:00
gtk_window_set_focus(GTK_WINDOW(window), NULL);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Stop selectable GTK message boxes clobbering PRIMARY. I noticed today that when GTK PuTTY puts up a message box such as a host key dialog, which calls our create_message_box function with selectable=true (so that the host key fingerprint can be conveniently copy-pasted), a side effect is to take the X11 PRIMARY selection away from whoever previously had it, even though the message box isn't actually selecting anything right now. I don't fully understand what's going on, but it apparently has something to do with 'select on focus' behaviour, in which tabbing into a selectable text control automatically selects its entire contents. That makes sense for edit boxes, but not really for this kind of thing. Unfortunately, GTK apparently has no per-widget configuration to turn that off. (The closest I found is not even per _application_: it lives in GtkSettings, whose documentation says that it's general across all GTK apps run by a user!) So instead I work around it by moving the gtk_label_set_selectable call to after the focus of the new window has already been sorted out. Ugly, but it seems to work.
2022-11-27 11:14:23 +00:00
#if GTK_CHECK_VERSION(2,0,0)
if (selectable) {
/*
* GTK selectable labels have a habit of selecting their
* entire contents when they gain focus. As far as I can see,
* an individual GtkLabel has no way to turn this off - source
* diving suggests that the only configurable option for it is
* "gtk-label-select-on-focus" in the cross-application
* GtkSettings, and there's no per-label or even
* per-application override.
*
* It's ugly to have text in a message box start up all
* selected, and also it interferes with any PRIMARY selection
* you might already have had. So for this purpose we'd prefer
* that the text doesn't _start off_ selected, but it should
* be selectable later.
*
* So we make the label selectable _now_, after the widget is
* shown and the focus has already gone wherever it's going.
*/
struct uctrl *uc = dlg_find_byctrl(dp, textctrl);
gtk_label_select_region(GTK_LABEL(uc->text), 0, 0);
gtk_label_set_selectable(GTK_LABEL(uc->text), true);
}
#else
(void)textctrl; /* placate warning */
#endif
GTK1 build fixes. Looks as if I haven't retried the GTK1 build for a while, and recent GTK frontend development has broken it. The selection revamp has pointed out that GTK1 didn't have the accessor function gtk_selection_data_get_selection(), the standard GdkAtom value GDK_SELECTION_CLIPBOARD, or keysyms for alphabetic characters; and also I had an initialisation of one of my own structure fields (dp->selparams) accidentally not guarded by the same GTK-versioning ifdef that controls whether or not it was defined.
2018-03-03 18:18:54 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
dp->currtreeitem = NULL;
dp->treeitems = NULL;
#else
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
dp->selparams = NULL;
GTK1 build fixes. Looks as if I haven't retried the GTK1 build for a while, and recent GTK frontend development has broken it. The selection revamp has pointed out that GTK1 didn't have the accessor function gtk_selection_data_get_selection(), the standard GdkAtom value GDK_SELECTION_CLIPBOARD, or keysyms for alphabetic characters; and also I had an initialisation of one of my own structure fields (dp->selparams) accidentally not guarded by the same GTK-versioning ifdef that controls whether or not it was defined.
2018-03-03 18:18:54 +00:00
#endif
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(window), "destroy",
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
G_CALLBACK(dlgparam_destroy), dp);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(window), "key_press_event",
Introduce a non-modal create_message_box(). This does the bulk of the work previously done by message_box() proper, but takes a pointer to a result-reporting callback function identical to the one we pass to create_config_box(). The modal version of message_box() still exists and is a small wrapper on this function, running its own subsidiary gtk_main() loop which the result callback terminates. But now I can start switching over individual uses of message_box() to the non-modal version, and when that's done, remove the modal function completely.
2017-11-26 14:29:31 +00:00
G_CALLBACK(win_key_press), dp);
return window;
}
GTK: add a callback to create_message_box. This lets the caller of create_message_box modify the dialog in small ways without having to repeat all the rest of the hard work as well.
2021-03-13 11:05:39 +00:00
GtkWidget *create_message_box(
GtkWidget *parentwin, const char *title, const char *msg, int minwid,
bool selectable, const struct message_box_buttons *buttons,
post_dialog_fn_t after, void *afterctx)
{
return create_message_box_general(
parentwin, title, msg, minwid, selectable, buttons, after, afterctx,
NULL /* action_postproc */, NULL /* postproc_ctx */);
}
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
struct confirm_ssh_host_key_dialog_ctx {
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
char *host;
int port;
char *keytype;
char *keystr;
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
char *more_info;
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
void (*callback)(void *callback_ctx, SeatPromptResult result);
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
void *callback_ctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Seat *seat;
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
GtkWidget *main_dialog;
GtkWidget *more_info_dialog;
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
};
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
static void confirm_ssh_host_key_result_callback(void *vctx, int result)
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
{
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
struct confirm_ssh_host_key_dialog_ctx *ctx =
(struct confirm_ssh_host_key_dialog_ctx *)vctx;
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
if (result >= 0) {
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult logical_result;
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
/*
* Convert the dialog-box return value (one of three
* possibilities) into the return value we pass back to the SSH
* code (one of only two possibilities, because the SSH code
* doesn't care whether we saved the host key or not).
*/
if (result == 2) {
New Seat method, seat_nonfatal(). This is like the seat-independent nonfatal(), but specifies a Seat, which allows the GUI dialog box to have the right terminal window as its parent (if there are multiple ones). Changed over all the nonfatal() calls in the code base that could be localised to a Seat, which means all the ones that come up if something goes horribly wrong in host key storage. To make that possible, I've added a 'seat' parameter to store_host_key(); it turns out that all its call sites had one available already.
2022-09-13 07:49:38 +00:00
store_host_key(ctx->seat, ctx->host, ctx->port,
ctx->keytype, ctx->keystr);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
logical_result = SPR_OK;
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
} else if (result == 1) {
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
logical_result = SPR_OK;
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
} else {
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
logical_result = SPR_USER_ABORT;
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
}
ctx->callback(ctx->callback_ctx, logical_result);
}
/*
* Clean up this context structure, whether or not a result was
* ever actually delivered from the dialog box.
*/
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
unregister_dialog(ctx->seat, DIALOG_SLOT_NETWORK_PROMPT);
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
if (ctx->more_info_dialog)
gtk_widget_destroy(ctx->more_info_dialog);
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
sfree(ctx->host);
sfree(ctx->keytype);
sfree(ctx->keystr);
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
sfree(ctx->more_info);
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
sfree(ctx);
}
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
static GtkWidget *add_more_info_button(GtkWidget *w, void *vctx)
{
GtkWidget *box = gtk_hbox_new(false, 10);
gtk_widget_show(box);
gtk_box_pack_end(GTK_BOX(box), w, false, true, 0);
GtkWidget *button = gtk_button_new_with_label("More info...");
gtk_widget_show(button);
gtk_box_pack_start(GTK_BOX(box), button, false, true, 0);
*(GtkWidget **)vctx = button;
return box;
}
static void more_info_closed(void *vctx, int result)
{
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
struct confirm_ssh_host_key_dialog_ctx *ctx =
(struct confirm_ssh_host_key_dialog_ctx *)vctx;
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
ctx->more_info_dialog = NULL;
}
static void more_info_button_clicked(GtkButton *button, gpointer vctx)
{
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
struct confirm_ssh_host_key_dialog_ctx *ctx =
(struct confirm_ssh_host_key_dialog_ctx *)vctx;
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
if (ctx->more_info_dialog)
return;
ctx->more_info_dialog = create_message_box(
ctx->main_dialog, "Host key information", ctx->more_info,
string_width("SHA256 fingerprint: ecdsa-sha2-nistp521 521 "
"abcdefghkmnopqrsuvwxyzABCDEFGHJKLMNOPQRSTUW"), true,
&buttons_ok, more_info_closed, ctx);
}
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
const SeatDialogPromptDescriptions *gtk_seat_prompt_descriptions(Seat *seat)
{
static const SeatDialogPromptDescriptions descs = {
.hk_accept_action = "press \"Accept\"",
.hk_connect_once_action = "press \"Connect Once\"",
.hk_cancel_action = "press \"Cancel\"",
.hk_cancel_action_Participle = "Pressing \"Cancel\"",
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
.weak_accept_action = "press \"Yes\"",
.weak_cancel_action = "press \"No\"",
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
};
return &descs;
}
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
/*
* Format a SeatDialogText into a strbuf, also adjusting the box width
* to cope with displayed text. Returns the dialog box title.
*/
static const char *gtk_format_seatdialogtext(
SeatDialogText *text, strbuf *dlg_text, int *width)
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
{
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
const char *dlg_title = NULL;
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
for (SeatDialogTextItem *item = text->items,
*end = item + text->nitems; item < end; item++) {
switch (item->type) {
case SDT_PARA:
put_fmt(dlg_text, "%s\n\n", item->text);
break;
case SDT_DISPLAY: {
put_fmt(dlg_text, "%s\n\n", item->text);
int thiswidth = string_width(item->text);
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
if (*width < thiswidth)
*width = thiswidth;
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
break;
}
case SDT_SCARY_HEADING:
/* Can't change font size or weight in this context */
put_fmt(dlg_text, "%s\n\n", item->text);
break;
case SDT_TITLE:
dlg_title = item->text;
break;
default:
break;
}
}
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
/*
* Trim trailing newlines.
*/
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
while (strbuf_chomp(dlg_text, '\n'));
Pass more information to interactive host key check. Now we pass the whole set of fingerprints, and also a displayable format for the full host public key. NFC: this commit doesn't modify any of the host key prompts to _use_ any of the new information. That's coming next.
2021-03-13 10:59:47 +00:00
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
return dlg_title;
}
SeatPromptResult gtk_seat_confirm_ssh_host_key(
Seat *seat, const char *host, int port, const char *keytype,
char *keystr, SeatDialogText *text, HelpCtx helpctx,
void (*callback)(void *ctx, SeatPromptResult result), void *ctx)
{
static const struct message_box_button button_array_hostkey[] = {
{"Accept", 'a', 0, 2},
{"Connect Once", 'o', 0, 1},
{"Cancel", 'c', -1, 0},
};
static const struct message_box_buttons buttons_hostkey = {
button_array_hostkey, lenof(button_array_hostkey),
};
int width = string_width("default dialog width determination string");
strbuf *dlg_text = strbuf_new();
const char *dlg_title = gtk_format_seatdialogtext(text, dlg_text, &width);
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
GtkWidget *mainwin, *msgbox;
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
struct confirm_ssh_host_key_dialog_ctx *result_ctx =
snew(struct confirm_ssh_host_key_dialog_ctx);
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
result_ctx->callback = callback;
result_ctx->callback_ctx = ctx;
result_ctx->host = dupstr(host);
result_ctx->port = port;
result_ctx->keytype = dupstr(keytype);
result_ctx->keystr = dupstr(keystr);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
result_ctx->seat = seat;
Make the GTK host-key verification box non-modal. I've switched it to using the new non-modal create_message_box, and provided a callback function which handles the cleanup afterwards. I had expected this to be a lot more work, because I'd imagined that I'd have to contort the coroutines in ssh.c to give them the ability to wait for an asynchronously delivered result from that user prompt. But in fact that wasn't necessary, because just such a mechanism has been sitting there unused since commit 8574822b9 in 2005, when I added it as part of my _previous_ attempt to write an OS X front end! (The abandoned one written in native ObjC + Cocoa.)
2017-11-26 14:29:42 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
mainwin = GTK_WIDGET(gtk_seat_get_window(seat));
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
GtkWidget *more_info_button = NULL;
msgbox = create_message_box_general(
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
mainwin, dlg_title, dlg_text->s, width, true,
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
&buttons_hostkey, confirm_ssh_host_key_result_callback, result_ctx,
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
add_more_info_button, &more_info_button);
result_ctx->main_dialog = msgbox;
result_ctx->more_info_dialog = NULL;
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
strbuf *moreinfo = strbuf_new();
for (SeatDialogTextItem *item = text->items,
*end = item + text->nitems; item < end; item++) {
switch (item->type) {
case SDT_MORE_INFO_KEY:
put_fmt(moreinfo, "%s", item->text);
break;
case SDT_MORE_INFO_VALUE_SHORT:
put_fmt(moreinfo, ": %s\n", item->text);
break;
case SDT_MORE_INFO_VALUE_BLOB:
/* We have to manually wrap the public key, or else the GtkLabel
* will resize itself to accommodate the longest word, which will
* lead to a hilariously wide message box. */
Fix regressions in Gtk host key "More info". A description like "SHA256 fingerprint:" could run into the previous public key blob; and add a missing colon.
2022-10-21 18:01:58 +00:00
put_byte(moreinfo, ':');
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
for (const char *p = item->text, *q = p + strlen(p); p < q ;) {
size_t linelen = q-p;
if (linelen > 72)
linelen = 72;
put_byte(moreinfo, '\n');
put_data(moreinfo, p, linelen);
p += linelen;
}
Fix regressions in Gtk host key "More info". A description like "SHA256 fingerprint:" could run into the previous public key blob; and add a missing colon.
2022-10-21 18:01:58 +00:00
put_byte(moreinfo, '\n');
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
break;
default:
break;
}
}
result_ctx->more_info = strbuf_to_str(moreinfo);
GUI host key prompts: add 'More info' subdialog. This behaves like the 'i' keystroke I just added to the console host key prompts: it shows you all fingerprints and the full public key.
2021-03-13 11:06:32 +00:00
g_signal_connect(G_OBJECT(more_info_button), "clicked",
G_CALLBACK(more_info_button_clicked), result_ctx);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
register_dialog(seat, DIALOG_SLOT_NETWORK_PROMPT, msgbox);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
strbuf_free(dlg_text);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
return SPR_INCOMPLETE; /* dialog still in progress */
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
struct simple_prompt_result_spr_ctx {
void (*callback)(void *callback_ctx, SeatPromptResult spr);
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
void *callback_ctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Seat *seat;
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
enum DialogSlot dialog_slot;
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
};
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
static void simple_prompt_result_spr_callback(void *vctx, int result)
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
{
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
struct simple_prompt_result_spr_ctx *ctx =
(struct simple_prompt_result_spr_ctx *)vctx;
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
GTK: unregister dialog boxes before delivering the result. When the user clicks 'yes' to a 'weak crypto primitive' warning, and another such warning is pending next in line, we were failing an assertion when ssh2transport called register_dialog() for the second warning box, because the result callback in gtkdlg.c had not called unregister_dialog() for the previous one yet. Now that's done before rather than after delivering the result to the dialog's client.
2019-01-13 17:14:08 +00:00
unregister_dialog(ctx->seat, ctx->dialog_slot);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
if (result == 0)
ctx->callback(ctx->callback_ctx, SPR_USER_ABORT);
else if (result > 0)
ctx->callback(ctx->callback_ctx, SPR_OK);
/* if <0, we're cleaning up for some other reason */
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
/*
* Clean up this context structure, whether or not a result was
* ever actually delivered from the dialog box.
*/
sfree(ctx);
}
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
/*
Add a preference list for SSH-2 key exchange algorithms, on a new "Kex" panel (which will gain more content anon). Retire BUG_SSH2_DH_GEX and add a backwards-compatibility wart, since we never did find a way of automatically detecting this alleged server bug, and in any case there was only ever one report (<3D91F3B5.7030309@inwind.it>, FWIW). Also generalise askcipher() to a new askalg() (thus touching all the front-ends). I've made some attempt to document what SSH key exchange is and why you care, but it could use some review for clarity (and outright lies). [originally from svn r5022]
2004-12-23 02:24:07 +00:00
* Ask whether the selected algorithm is acceptable (since it was
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
* below the configured 'warn' threshold).
*/
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult gtk_seat_confirm_weak_crypto_primitive(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
Seat *seat, SeatDialogText *text,
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
void (*callback)(void *ctx, SeatPromptResult result), void *ctx)
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
{
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
struct simple_prompt_result_spr_ctx *result_ctx;
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
GtkWidget *mainwin, *msgbox;
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
int width = string_width("Reasonably long line of text "
"as a width template");
strbuf *dlg_text = strbuf_new();
const char *dlg_title = gtk_format_seatdialogtext(text, dlg_text, &width);
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
result_ctx = snew(struct simple_prompt_result_spr_ctx);
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
result_ctx->callback = callback;
result_ctx->callback_ctx = ctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
result_ctx->seat = seat;
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
result_ctx->dialog_slot = DIALOG_SLOT_NETWORK_PROMPT;
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
mainwin = GTK_WIDGET(gtk_seat_get_window(seat));
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
msgbox = create_message_box(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
mainwin, dlg_title, dlg_text->s, width, false,
&buttons_yn, simple_prompt_result_spr_callback, result_ctx);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
register_dialog(seat, result_ctx->dialog_slot, msgbox);
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
strbuf_free(dlg_text);
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
return SPR_INCOMPLETE;
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult gtk_seat_confirm_weak_cached_hostkey(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
Seat *seat, SeatDialogText *text,
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
void (*callback)(void *ctx, SeatPromptResult result), void *ctx)
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
{
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
struct simple_prompt_result_spr_ctx *result_ctx;
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
GtkWidget *mainwin, *msgbox;
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
int width = string_width("is ecdsa-nistp521, which is below the configured"
" warning threshold.");
strbuf *dlg_text = strbuf_new();
const char *dlg_title = gtk_format_seatdialogtext(text, dlg_text, &width);
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
result_ctx = snew(struct simple_prompt_result_spr_ctx);
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
result_ctx->callback = callback;
result_ctx->callback_ctx = ctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
result_ctx->seat = seat;
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
result_ctx->dialog_slot = DIALOG_SLOT_NETWORK_PROMPT;
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
mainwin = GTK_WIDGET(gtk_seat_get_window(seat));
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
msgbox = create_message_box(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
mainwin, dlg_title, dlg_text->s, width, false,
&buttons_yn, simple_prompt_result_spr_callback, result_ctx);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
register_dialog(seat, result_ctx->dialog_slot, msgbox);
Make GTK askalg() and askhk() non-modal. This follows exactly the same pattern as for verify_ssh_host_key, but the results of the dialog box are simpler (a plain yes-no response), so the two dialog types can share a callback.
2017-11-26 15:13:08 +00:00
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
strbuf_free(dlg_text);
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
return SPR_INCOMPLETE;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
void old_keyfile_warning(void)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Checkin of last night's work on GTK message boxes. Unix PuTTY now has proper GUI prompts for host keys etc, so it should now be usable without a controlling tty. [originally from svn r3028]
2003-03-31 11:21:07 +00:00
/*
* This should never happen on Unix. We hope.
*/
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void nonfatal_message_box(void *window, const char *msg)
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
{
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
char *title = dupcat(appname, " Error");
Make nonfatal() nonmodal. This one was completely trivial, except that while I was at it, I took the opportunity to put the right program name in the window title.
2017-11-26 17:55:00 +00:00
create_message_box(
window, title, msg,
string_width("REASONABLY LONG LINE OF TEXT FOR BASIC SANITY"),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
false, &buttons_ok, trivial_post_dialog_fn, NULL);
Make nonfatal() nonmodal. This one was completely trivial, except that while I was at it, I took the opportunity to put the right program name in the window title.
2017-11-26 17:55:00 +00:00
sfree(title);
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
}
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void nonfatal(const char *p, ...)
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
{
va_list ap;
char *msg;
va_start(ap, p);
msg = dupvprintf(p, ap);
va_end(ap);
Fix cut-and-paste errors in nonfatal() implementations. Unix GUI programs should not say 'Fatal Error' in the message box title, and Plink should not destroy its logging context as a side effect of printing a non-fatal error. Both appear to have been due to inattentive cut and paste from the pre-existing fatal error functions. [originally from svn r10044]
2013-09-23 14:35:08 +00:00
nonfatal_message_box(NULL, msg);
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
sfree(msg);
}
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
static GtkWidget *aboutbox = NULL;
Gtk: handle WM close on About box. Previously this would prevent the About box ever being opened again.
2021-04-05 16:50:02 +00:00
static void about_window_destroyed(GtkWidget *widget, gpointer data)
{
aboutbox = NULL;
}
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
static void about_close_clicked(GtkButton *button, gpointer data)
{
gtk_widget_destroy(aboutbox);
aboutbox = NULL;
}
Make sure Escape terminates the About box. I think it only did so in GTK2 by virtue of the About box being a GtkDialog. But in GTK3 I've abandoned GtkDialog for not being flexible enough, so I have to process the Escape key myself.
2015-09-26 13:09:27 +00:00
static void about_key_press(GtkWidget *widget, GdkEventKey *event,
gpointer data)
{
if (event->keyval == GDK_KEY_Escape && aboutbox) {
gtk_widget_destroy(aboutbox);
aboutbox = NULL;
}
}
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
static void licence_clicked(GtkButton *button, gpointer data)
{
char *title;
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
title = dupcat(appname, " Licence");
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
assert(aboutbox != NULL);
Make the Licence message box non-modal.
2017-11-26 17:32:01 +00:00
create_message_box(aboutbox, title, LICENCE_TEXT("\n\n"),
string_width("LONGISH LINE OF TEXT SO THE LICENCE"
" BOX ISN'T EXCESSIVELY TALL AND THIN"),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
true, &buttons_ok, trivial_post_dialog_fn, NULL);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
sfree(title);
}
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
void about_box(void *window)
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
{
GtkWidget *w;
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
GtkBox *action_area;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
char *title;
if (aboutbox) {
gtk_widget_grab_focus(aboutbox);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
aboutbox = our_dialog_new();
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_container_set_border_width(GTK_CONTAINER(aboutbox), 10);
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
title = dupcat("About ", appname);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_window_set_title(GTK_WINDOW(aboutbox), title);
sfree(title);
Gtk: handle WM close on About box. Previously this would prevent the About box ever being opened again.
2021-04-05 16:50:02 +00:00
g_signal_connect(G_OBJECT(aboutbox), "destroy",
G_CALLBACK(about_window_destroyed), NULL);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
w = gtk_button_new_with_label("Close");
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_widget_set_can_default(w, true);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_window_set_default(GTK_WINDOW(aboutbox), w);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
action_area = our_dialog_make_action_hbox(GTK_WINDOW(aboutbox));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_box_pack_end(action_area, w, false, false, 0);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(w), "clicked",
G_CALLBACK(about_close_clicked), NULL);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_widget_show(w);
w = gtk_button_new_with_label("View Licence");
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_widget_set_can_default(w, true);
gtk_box_pack_end(action_area, w, false, false, 0);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(w), "clicked",
G_CALLBACK(licence_clicked), NULL);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_widget_show(w);
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 12:32:48 +00:00
{
Include 'build info' in all --version text and About boxes. This shows the build platform (32- vs 64-bit in particular, and also whether Unix GTK builds were compiled with or without the X11 pieces), what compiler was used to build the binary, and any interesting build options that might have been set on the make command line (especially, but not limited to, the security-damaging ones like NO_SECURITY or UNPROTECT). This will probably be useful all over the place, but in particular it should allow the different Windows binaries to be told apart! Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by allowing the various About boxes to contain free text and also ensuring they could be copied and pasted easily as part of a bug report.
2017-01-21 14:55:53 +00:00
char *buildinfo_text = buildinfo("\n");
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
char *label_text = dupprintf(
"%s\n\n%s\n\n%s\n\n%s",
appname, ver, buildinfo_text,
"Copyright " SHORT_COPYRIGHT_DETAILS ". All rights reserved");
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 12:32:48 +00:00
w = gtk_label_new(label_text);
gtk_label_set_justify(GTK_LABEL(w), GTK_JUSTIFY_CENTER);
#if GTK_CHECK_VERSION(2,0,0)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_label_set_selectable(GTK_LABEL(w), true);
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 12:32:48 +00:00
#endif
sfree(label_text);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
our_dialog_add_to_content_area(GTK_WINDOW(aboutbox), w, false, false, 0);
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 12:32:48 +00:00
#if GTK_CHECK_VERSION(2,0,0)
/*
Remove the modal message_box function completely. Now there's nothing left that calls it, it's obsolete.
2017-11-26 20:01:16 +00:00
* Same precautions against initial select-all as in
* create_message_box().
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 12:32:48 +00:00
*/
gtk_widget_grab_focus(w);
gtk_label_select_region(GTK_LABEL(w), 0, 0);
#endif
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_widget_show(w);
Make sure Escape terminates the About box. I think it only did so in GTK2 by virtue of the About box being a GtkDialog. But in GTK3 I've abandoned GtkDialog for not being flexible enough, so I have to process the Escape key myself.
2015-09-26 13:09:27 +00:00
g_signal_connect(G_OBJECT(aboutbox), "key_press_event",
G_CALLBACK(about_key_press), NULL);
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
set_transient_window_pos(GTK_WIDGET(window), aboutbox);
Fill in some more of the OS X menu bar. This still isn't complete: I also need to add the variable collections of things like mid-session special commands and saved session names, and also I need to try to grey out menu items when they're not applicable. But it's a start.
2017-12-18 11:46:48 +00:00
if (window)
gtk_window_set_transient_for(GTK_WINDOW(aboutbox),
GTK_WINDOW(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 12:32:48 +00:00
gtk_container_set_focus_child(GTK_CONTAINER(aboutbox), NULL);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
gtk_widget_show(aboutbox);
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 12:32:48 +00:00
gtk_window_set_focus(GTK_WINDOW(aboutbox), NULL);
Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm. This menu is not yet fully populated, but it has an About box (yet another licence location :-/ ) and supports the new configurable specials menu (thus making Unix PuTTY do one tiny thing which OpenSSH-in-a-pterm can't :-). [originally from svn r3062]
2003-04-05 16:05:00 +00:00
}
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
#define LOGEVENT_INITIAL_MAX 128
#define LOGEVENT_CIRCULAR_MAX 128
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
struct eventlog_stuff {
GtkWidget *parentwin, *window;
struct controlbox *eventbox;
struct Shortcuts scs;
struct dlgparam dp;
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *listctrl;
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
char **events_initial;
char **events_circular;
int ninitial, ncircular, circular_first;
Replace several ad-hoc string formatters with strbuf. uxnet.c's sk_namelookup and the sorting-key construction in pangofont_enum_fonts() were both using s[n]printf and strncpy into buffers that had no real need to be fixed-size; format_telnet_command and the GTK Event Log selection-data builder were doing their own sresize loops, but now we have strbuf they can just use that and save redoing the same work.
2018-12-01 09:35:52 +00:00
strbuf *seldata;
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
int sellen;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool ignore_selchange;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
};
static void eventlog_destroy(GtkWidget *widget, gpointer data)
{
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlog_stuff *es = (eventlog_stuff *)data;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
es->window = NULL;
dlg_cleanup(&es->dp);
ctrl_free_box(es->eventbox);
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
static void eventlog_ok_handler(dlgcontrol *ctrl, dlgparam *dp,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *data, int event)
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
{
if (event == EVENT_ACTION)
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
dlg_end(dp, 0);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
static void eventlog_list_handler(dlgcontrol *ctrl, dlgparam *dp,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *data, int event)
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
{
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlog_stuff *es = (eventlog_stuff *)data;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
if (event == EVENT_REFRESH) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
dlg_update_start(ctrl, dp);
dlg_listbox_clear(ctrl, dp);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
for (i = 0; i < es->ninitial; i++) {
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
dlg_listbox_add(ctrl, dp, es->events_initial[i]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
for (i = 0; i < es->ncircular; i++) {
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
dlg_listbox_add(ctrl, dp, es->events_circular[(es->circular_first + i) % LOGEVENT_CIRCULAR_MAX]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
dlg_update_done(ctrl, dp);
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
} else if (event == EVENT_SELCHANGE) {
int i;
/*
* If this SELCHANGE event is happening as a result of
* deliberate deselection because someone else has grabbed
* the selection, the last thing we want to do is pre-empt
* them.
*/
if (es->ignore_selchange)
return;
/*
* Construct the data to use as the selection.
*/
New functions to shrink a strbuf. These are better than my previous approach of just assigning to sb->len, because firstly they check by assertion that the new length is within range, and secondly they preserve the invariant that the byte stored in the buffer just after the length runs out is \0. Switched to using the new functions everywhere a grep could turn up opportunities.
2020-01-21 20:16:28 +00:00
strbuf_clear(es->seldata);
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
for (i = 0; i < es->ninitial; i++) {
Replace several ad-hoc string formatters with strbuf. uxnet.c's sk_namelookup and the sorting-key construction in pangofont_enum_fonts() were both using s[n]printf and strncpy into buffers that had no real need to be fixed-size; format_telnet_command and the GTK Event Log selection-data builder were doing their own sresize loops, but now we have strbuf they can just use that and save redoing the same work.
2018-12-01 09:35:52 +00:00
if (dlg_listbox_issel(ctrl, dp, i))
Generalise strbuf_catf() into put_fmt(). marshal.h now provides a macro put_fmt() which allows you to write arbitrary printf-formatted data to an arbitrary BinarySink. We already had this facility for strbufs in particular, in the form of strbuf_catf(). That was able to take advantage of knowing the inner structure of a strbuf to minimise memory allocation (it would snprintf directly into the strbuf's existing buffer if possible). For a general black-box BinarySink we can't do that, so instead we dupvprintf into a temporary buffer. For consistency, I've removed strbuf_catf, and converted all uses of it into the new put_fmt - and I've also added an extra vtable method in the BinarySink API, so that put_fmt can still use strbuf_catf's more efficient memory management when talking to a strbuf, and fall back to the simpler strategy when that's not available.
2021-11-19 10:23:32 +00:00
put_fmt(es->seldata, "%s\n", es->events_initial[i]);
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
}
for (i = 0; i < es->ncircular; i++) {
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
if (dlg_listbox_issel(ctrl, dp, es->ninitial + i)) {
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
int j = (es->circular_first + i) % LOGEVENT_CIRCULAR_MAX;
Generalise strbuf_catf() into put_fmt(). marshal.h now provides a macro put_fmt() which allows you to write arbitrary printf-formatted data to an arbitrary BinarySink. We already had this facility for strbufs in particular, in the form of strbuf_catf(). That was able to take advantage of knowing the inner structure of a strbuf to minimise memory allocation (it would snprintf directly into the strbuf's existing buffer if possible). For a general black-box BinarySink we can't do that, so instead we dupvprintf into a temporary buffer. For consistency, I've removed strbuf_catf, and converted all uses of it into the new put_fmt - and I've also added an extra vtable method in the BinarySink API, so that put_fmt can still use strbuf_catf's more efficient memory management when talking to a strbuf, and fall back to the simpler strategy when that's not available.
2021-11-19 10:23:32 +00:00
put_fmt(es->seldata, "%s\n", es->events_circular[j]);
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
}
}
if (gtk_selection_owner_set(es->window, GDK_SELECTION_PRIMARY,
GDK_CURRENT_TIME)) {
gtk_selection_add_target(es->window, GDK_SELECTION_PRIMARY,
GDK_SELECTION_TYPE_STRING, 1);
gtk_selection_add_target(es->window, GDK_SELECTION_PRIMARY,
compound_text_atom, 1);
}
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
}
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
void eventlog_selection_get(GtkWidget *widget, GtkSelectionData *seldata,
guint info, guint time_stamp, gpointer data)
{
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlog_stuff *es = (eventlog_stuff *)data;
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
gtk_selection_data_set(seldata, gtk_selection_data_get_target(seldata), 8,
Replace several ad-hoc string formatters with strbuf. uxnet.c's sk_namelookup and the sorting-key construction in pangofont_enum_fonts() were both using s[n]printf and strncpy into buffers that had no real need to be fixed-size; format_telnet_command and the GTK Event Log selection-data builder were doing their own sresize loops, but now we have strbuf they can just use that and save redoing the same work.
2018-12-01 09:35:52 +00:00
es->seldata->u, es->seldata->len);
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
}
gint eventlog_selection_clear(GtkWidget *widget, GdkEventSelection *seldata,
gpointer data)
{
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlog_stuff *es = (eventlog_stuff *)data;
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
struct uctrl *uc;
/*
* Deselect everything in the list box.
*/
uc = dlg_find_byctrl(&es->dp, es->listctrl);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
es->ignore_selchange = true;
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
assert(uc->list);
gtk_list_unselect_all(GTK_LIST(uc->list));
#else
Rename a structure field to avoid clashing with one of the old GTK1 ones. (I'm going to merge the GTK1 list code back in under ifdefs, and I want none of the disputed structure fields to have the same names, so that I'll reliably be told by the compiler if I keep the wrong piece of code outside the ifdef.) [originally from svn r7965]
2008-04-04 10:16:24 +00:00
assert(uc->treeview);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_tree_selection_unselect_all(
gtk_tree_view_get_selection(GTK_TREE_VIEW(uc->treeview)));
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#endif
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
es->ignore_selchange = false;
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Cutting and pasting from the Unix Event Log. [originally from svn r3095]
2003-04-11 17:40:52 +00:00
}
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
void showeventlog(eventlog_stuff *es, void *parentwin)
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
{
GtkWidget *window, *w0, *w1;
GtkWidget *parent = GTK_WIDGET(parentwin);
struct controlset *s0, *s1;
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *c;
Update all the list box code in gtkdlg.c to use the new-style GTK2 GtkTreeView, GtkComboBox and GtkComboBoxEntry instead of the various old deprecated stuff. Immediate benefit: GTK2 natively supports real drag lists, hooray! [originally from svn r7959]
2008-04-02 14:48:06 +00:00
int index;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
char *title;
if (es->window) {
gtk_widget_grab_focus(es->window);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
dlg_init(&es->dp);
for (index = 0; index < lenof(es->scs.sc); index++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
es->scs.sc[index].action = SHORTCUT_EMPTY;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
es->eventbox = ctrl_new_box();
s0 = ctrl_getset(es->eventbox, "", "", "");
ctrl_columns(s0, 3, 33, 34, 33);
c = ctrl_pushbutton(s0, "Close", 'c', HELPCTX(no_help),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
eventlog_ok_handler, P(NULL));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
c->column = 1;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
c->button.isdefault = true;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
s1 = ctrl_getset(es->eventbox, "x", "", "");
es->listctrl = c = ctrl_listbox(s1, NULL, NO_SHORTCUT, HELPCTX(no_help),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
eventlog_list_handler, P(es));
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
c->listbox.height = 10;
c->listbox.multisel = 2;
c->listbox.ncols = 3;
c->listbox.percentages = snewn(3, int);
c->listbox.percentages[0] = 25;
c->listbox.percentages[1] = 10;
c->listbox.percentages[2] = 65;
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
es->window = window = our_dialog_new();
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
title = dupcat(appname, " Event Log");
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
gtk_window_set_title(GTK_WINDOW(window), title);
sfree(title);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
w0 = layout_ctrls(&es->dp, NULL, &es->scs, s0, GTK_WINDOW(window));
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
our_dialog_set_action_area(GTK_WINDOW(window), w0);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
gtk_widget_show(w0);
Don't implicitly load a session if Session pane not active. If you select an entry in the saved sessions list box, but without double-clicking to actually load it, and then you hit OK, the config- box code will automatically load it. That just saves one click in a common situation. But in order to load that session, the config-box system first has to ask the list-box control _which_ session is selected. On Windows, this causes an assertion failure if the user has switched away from the Session panel to some other panel of the config box, because when the list box isn't on screen, its Windows control object is actually destroyed. I think a sensible answer is that we shouldn't be doing that implicit load behaviour in any case if the list box isn't _visible_: silently loading and launching a session someone selected a lot of UI actions ago wasn't really the point. So now I make that behaviour only happen when the list box (i.e. the Session panel) _is_ visible. That should prevent the assertion failure on Windows, but the UI effect is cross- platform, applying even on GTK where the control objects for invisible panels persist and so the assertion failure didn't happen. I think it's a reasonable UI change to make globally. In order to implement it, I've had to invent a new query function so that config.c can tell whether a given control is visible. In order to do that on GTK, I had to give each control a pointer to the 'selparam' structure describing its config-box pane, so that query function could check it against the current one - and in order to do _that_, I had to first arrange that those 'selparam' structures have stable addresses from the moment they're first created, which meant adding a layer of indirection so that the array of them in the top-level dlgparam structure is now an array of _pointers_ rather than of actual structs. (That way, realloc half way through config box creation can't invalidate the important pointer values.)
2019-06-29 16:12:47 +00:00
w1 = layout_ctrls(&es->dp, NULL, &es->scs, s1, GTK_WINDOW(window));
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
gtk_container_set_border_width(GTK_CONTAINER(w1), 10);
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_widget_set_size_request(
w1, 20 + string_width("LINE OF TEXT GIVING WIDTH OF EVENT LOG IS "
"QUITE LONG 'COS SSH LOG ENTRIES ARE WIDE"),
-1);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
our_dialog_add_to_content_area(GTK_WINDOW(window), w1, true, true, 0);
GTK: allow Event Log list box to grow vertically. Now, when you resize the Event Log window, the list box grows in both directions. Previously, as a side effect of the Columns-based layout, it grew only horizontally. I've arranged this by adding an extra wrinkle to the Columns layout system, which allows you to tag _exactly one_ widget in the whole container as the 'vexpand' widget. When the Columns is size-allocated taller than its minimum height, the vexpand widget is given all the extra space. This technique ports naturally across all versions of GTK (since the hard part is done in my own code). But it's limited: you can't set more than one widget to be vexpand (which saves having to figure out whether they're side by side and can expand in parallel, or vertically separated and each have to get half the available extra space, etc). And in complex layouts where the widget you really want to expand is in a sub-Columns, there's no system for recursively searching down to find it. In other words, this is a one-shot bodge for the Event Log, and it will want more work if we ever plan to extend it to list boxes in the main config dialog.
2021-12-21 10:53:41 +00:00
{
struct uctrl *uc = dlg_find_byctrl(&es->dp, es->listctrl);
columns_vexpand(COLUMNS(w1), uc->toplevel);
}
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
gtk_widget_show(w1);
es->dp.data = es;
es->dp.shortcuts = &es->scs;
es->dp.lastfocus = NULL;
es->dp.retval = 0;
es->dp.window = window;
dlg_refresh(NULL, &es->dp);
if (parent) {
Minor improvements to subsidiary window placement; with any luck the Event Log should go off the side of the screen rather less often now. [originally from svn r3088]
2003-04-10 08:53:43 +00:00
set_transient_window_pos(parent, window);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_set_transient_for(GTK_WINDOW(window),
GTK_WINDOW(parent));
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
gtk_widget_show(window);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(window), "destroy",
G_CALLBACK(eventlog_destroy), es);
g_signal_connect(G_OBJECT(window), "key_press_event",
G_CALLBACK(win_key_press), &es->dp);
g_signal_connect(G_OBJECT(window), "selection_get",
G_CALLBACK(eventlog_selection_get), es);
g_signal_connect(G_OBJECT(window), "selection_clear_event",
G_CALLBACK(eventlog_selection_clear), es);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlog_stuff *eventlogstuff_new(void)
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
{
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
eventlog_stuff *es = snew(eventlog_stuff);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
memset(es, 0, sizeof(*es));
Replace several ad-hoc string formatters with strbuf. uxnet.c's sk_namelookup and the sorting-key construction in pangofont_enum_fonts() were both using s[n]printf and strncpy into buffers that had no real need to be fixed-size; format_telnet_command and the GTK Event Log selection-data builder were doing their own sresize loops, but now we have strbuf they can just use that and save redoing the same work.
2018-12-01 09:35:52 +00:00
es->seldata = strbuf_new();
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
return es;
}
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
void eventlogstuff_free(eventlog_stuff *es)
{
int i;
if (es->events_initial) {
for (i = 0; i < LOGEVENT_INITIAL_MAX; i++)
sfree(es->events_initial[i]);
sfree(es->events_initial);
}
if (es->events_circular) {
for (i = 0; i < LOGEVENT_CIRCULAR_MAX; i++)
sfree(es->events_circular[i]);
sfree(es->events_circular);
}
Replace several ad-hoc string formatters with strbuf. uxnet.c's sk_namelookup and the sorting-key construction in pangofont_enum_fonts() were both using s[n]printf and strncpy into buffers that had no real need to be fixed-size; format_telnet_command and the GTK Event Log selection-data builder were doing their own sresize loops, but now we have strbuf they can just use that and save redoing the same work.
2018-12-01 09:35:52 +00:00
strbuf_free(es->seldata);
Tidy up 'eventlog_stuff' structure and fix leak. This is the structure that stores the truncated version of the Event Log data to be displayed by the GTK Event Log dialog. It persists for the lifetime of the parent SSH window, so it was deliberate that it wasn't freed on destruction of the dialog itself, but I also forgot to free it on destruction of the SSH window. (This will be more important in multi-connection process architectures like the OS X port, of course.) While I'm at it, I'll follow my recent practice by exposing the structure tag outside gtkdlg.c so that callers can more easily not confuse it with some other kind of void *.
2018-10-08 18:30:01 +00:00
sfree(es);
}
void logevent_dlg(eventlog_stuff *es, const char *string)
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
{
char timebuf[40];
New function ltime() returns a struct tm of the current local time. Fixes crashes when time() returns (time_t)-1 on Windows by using the Win32 GetLocalTime() function. (The Unix implementation still just uses time() and localtime().) [originally from svn r5086]
2005-01-09 14:27:48 +00:00
struct tm tm;
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
char **location;
size_t i;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
if (es->ninitial == 0) {
es->events_initial = sresize(es->events_initial, LOGEVENT_INITIAL_MAX, char *);
for (i = 0; i < LOGEVENT_INITIAL_MAX; i++)
es->events_initial[i] = NULL;
es->events_circular = sresize(es->events_circular, LOGEVENT_CIRCULAR_MAX, char *);
for (i = 0; i < LOGEVENT_CIRCULAR_MAX; i++)
es->events_circular[i] = NULL;
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
if (es->ninitial < LOGEVENT_INITIAL_MAX)
location = &es->events_initial[es->ninitial];
else
location = &es->events_circular[(es->circular_first + es->ncircular) % LOGEVENT_CIRCULAR_MAX];
New function ltime() returns a struct tm of the current local time. Fixes crashes when time() returns (time_t)-1 on Windows by using the Win32 GetLocalTime() function. (The Unix implementation still just uses time() and localtime().) [originally from svn r5086]
2005-01-09 14:27:48 +00:00
tm=ltime();
strftime(timebuf, sizeof(timebuf), "%Y-%m-%d %H:%M:%S\t", &tm);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
sfree(*location);
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
*location = dupcat(timebuf, string);
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
if (es->window) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
dlg_listbox_add(es->listctrl, &es->dp, *location);
Don't grow logevent buf indefinitely The PuTTY GUIs (Unix and Windows) maintain an in-memory event log for display to users as they request. This uses ints for tracking eventlog size, which is subject to memory exhaustion and (given enough heap space) overflow attacks by servers (via, e.g., constant rekeying). Also a bounded log is more user-friendly. It is rare to want more than the initial logging and the logging from a few recent rekey events. The Windows fix has been tested using Dr. Memory as a valgrind substitute. No errors corresponding to the affected code showed up. The Dr. Memory results.txt was split into a file per-error and then grep Error $(grep -l windlg *)|cut -d: -f3-|sort |uniq -c was used to compare. Differences arose from different usage of the GUI, but no error could be traced to the code modified in this commit. The Unix fix has been tested using valgrind. We don't destroy the eventlog_stuff eventlog arrays, so we can't be entirely sure that we don't leak more than we did before, but from code inspection it looks like we don't (and anyways, if we leaked as much as before, just without the integer overflow, well, that's still an improvement).
2013-07-22 23:09:04 +00:00
}
if (es->ninitial < LOGEVENT_INITIAL_MAX) {
es->ninitial++;
} else if (es->ncircular < LOGEVENT_CIRCULAR_MAX) {
es->ncircular++;
} else if (es->ncircular == LOGEVENT_CIRCULAR_MAX) {
es->circular_first = (es->circular_first + 1) % LOGEVENT_CIRCULAR_MAX;
sfree(es->events_circular[es->circular_first]);
es->events_circular[es->circular_first] = dupstr("..");
Event Log for Unix PuTTY. Doesn't yet allow X selection of its contents, and doesn't automatically maintain scroll position at the bottom when new entries are added while the list is open, but it's a start. [originally from svn r3087]
2003-04-09 18:46:45 +00:00
}
}
When I implemented the GTK messagebox() function and everything that needed to use it, I completely forgot about askappend(). D'oh. [originally from svn r3101]
2003-04-11 18:44:05 +00:00
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
struct simple_prompt_result_int_ctx {
void (*callback)(void *callback_ctx, int result);
void *callback_ctx;
Seat *seat;
enum DialogSlot dialog_slot;
};
static void simple_prompt_result_int_callback(void *vctx, int result)
{
struct simple_prompt_result_int_ctx *ctx =
(struct simple_prompt_result_int_ctx *)vctx;
unregister_dialog(ctx->seat, ctx->dialog_slot);
if (result >= 0)
ctx->callback(ctx->callback_ctx, result);
/*
* Clean up this context structure, whether or not a result was
* ever actually delivered from the dialog box.
*/
sfree(ctx);
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
int gtkdlg_askappend(Seat *seat, Filename *filename,
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
void (*callback)(void *ctx, int result), void *ctx)
When I implemented the GTK messagebox() function and everything that needed to use it, I completely forgot about askappend(). D'oh. [originally from svn r3101]
2003-04-11 18:44:05 +00:00
{
static const char msgtemplate[] =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"The session log file \"%.*s\" already exists. "
"You can overwrite it with a new session log, "
"append your session log to the end of it, "
"or disable session logging for this session.";
Make the GTK message-box function non-variadic. Now, in place of a variadic argument list with four parameters per button and a terminating NULL, it takes a pointer to a struct which in turn contains an (array,length) pair of small per-button structures. In the process I've renamed the function from messagebox() to message_box(). Partly that was just because it gave me a convenient way to search the source for calls I hadn't converted yet, but also I've thought for a while that that missing underscore didn't really match the rest of my naming. NFCI. Partly this minor refactor has the virtue that we can reuse the more common button layouts without having to type them in at multiple places in the code (and, indeed, I've provided buttons_yn and buttons_ok for easy reuse, and could easily provide other things like yesnocancel any time I need them). But mostly it's because I'm about to split up message_box into multiple functions, and this saves me the hassle of deciding which ones to make variadic and which to pass an actual va_list to - particularly since messagebox() used to go over its variadic argument list twice, which always makes delegating it to another function that much more annoying.
2017-11-26 14:05:02 +00:00
static const struct message_box_button button_array_append[] = {
{"Overwrite", 'o', 1, 2},
{"Append", 'a', 0, 1},
{"Disable", 'd', -1, 0},
};
static const struct message_box_buttons buttons_append = {
button_array_append, lenof(button_array_append),
};
When I implemented the GTK messagebox() function and everything that needed to use it, I completely forgot about askappend(). D'oh. [originally from svn r3101]
2003-04-11 18:44:05 +00:00
char *message;
char *mbtitle;
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
struct simple_prompt_result_int_ctx *result_ctx;
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
GtkWidget *mainwin, *msgbox;
When I implemented the GTK messagebox() function and everything that needed to use it, I completely forgot about askappend(). D'oh. [originally from svn r3101]
2003-04-11 18:44:05 +00:00
Turn 'Filename' into a dynamically allocated type with no arbitrary length limit, just as I did to FontSpec yesterday. [originally from svn r9316]
2011-10-02 11:01:57 +00:00
message = dupprintf(msgtemplate, FILENAME_MAX, filename->path);
When I implemented the GTK messagebox() function and everything that needed to use it, I completely forgot about askappend(). D'oh. [originally from svn r3101]
2003-04-11 18:44:05 +00:00
mbtitle = dupprintf("%s Log to File", appname);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
result_ctx = snew(struct simple_prompt_result_int_ctx);
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
result_ctx->callback = callback;
result_ctx->callback_ctx = ctx;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
result_ctx->seat = seat;
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
result_ctx->dialog_slot = DIALOG_SLOT_LOGFILE_PROMPT;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
mainwin = GTK_WIDGET(gtk_seat_get_window(seat));
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
msgbox = create_message_box(
mainwin, mbtitle, message,
string_width("LINE OF TEXT SUITABLE FOR THE ASKAPPEND WIDTH"),
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
false, &buttons_append, simple_prompt_result_int_callback, result_ctx);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
register_dialog(seat, result_ctx->dialog_slot, msgbox);
When I implemented the GTK messagebox() function and everything that needed to use it, I completely forgot about askappend(). D'oh. [originally from svn r3101]
2003-04-11 18:44:05 +00:00
sfree(message);
sfree(mbtitle);
Make the askappend() prompt non-modal. This fits into a new dialog-box slot (because it might have to come up at the same time as a network prompt), and makes use of the existing callback system in logging.c which buffers the logging data until the user says what they want done with it.
2017-11-26 16:56:03 +00:00
return -1; /* dialog still in progress */
When I implemented the GTK messagebox() function and everything that needed to use it, I completely forgot about askappend(). D'oh. [originally from svn r3101]
2003-04-11 18:44:05 +00:00
}
Initial support for host certificates. Now we offer the OpenSSH certificate key types in our KEXINIT host key algorithm list, so that if the server has a certificate, they can send it to us. There's a new storage.h abstraction for representing a list of trusted host CAs, and which ones are trusted to certify hosts for what domains. This is stored outside the normal saved session data, because the whole point of host certificates is to avoid per-host faffing. Configuring this set of trusted CAs is done via a new GUI dialog box, separate from the main PuTTY config box (because it modifies a single set of settings across all saved sessions), which you can launch by clicking a button in the 'Host keys' pane. The GUI is pretty crude for the moment, and very much at a 'just about usable' stage right now. It will want some polishing. If we have no CA configured that matches the hostname, we don't offer to receive certified host keys in the first place. So for existing users who haven't set any of this up yet, nothing will immediately change. Currently, if we do offer to receive certified host keys and the server presents one signed by a CA we don't trust, PuTTY will bomb out unconditionally with an error, instead of offering a confirmation box. That's an unfinished part which I plan to fix before this goes into a release.
2022-04-22 11:07:24 +00:00
struct ca_config_box {
GtkWidget *window;
struct controlbox *cb;
struct Shortcuts scs;
New command-line option: 'putty --host-ca'. This causes PuTTY to bring up just the host CA configuration dialog box, and shut down once that box is dismissed. I can imagine it potentially being useful to users, but in the first instance, I expect it to be useful to _me_, because it will greatly streamline testing changes to the UI of that dialog!
2022-05-01 07:22:44 +00:00
bool quit_main;
Initial support for host certificates. Now we offer the OpenSSH certificate key types in our KEXINIT host key algorithm list, so that if the server has a certificate, they can send it to us. There's a new storage.h abstraction for representing a list of trusted host CAs, and which ones are trusted to certify hosts for what domains. This is stored outside the normal saved session data, because the whole point of host certificates is to avoid per-host faffing. Configuring this set of trusted CAs is done via a new GUI dialog box, separate from the main PuTTY config box (because it modifies a single set of settings across all saved sessions), which you can launch by clicking a button in the 'Host keys' pane. The GUI is pretty crude for the moment, and very much at a 'just about usable' stage right now. It will want some polishing. If we have no CA configured that matches the hostname, we don't offer to receive certified host keys in the first place. So for existing users who haven't set any of this up yet, nothing will immediately change. Currently, if we do offer to receive certified host keys and the server presents one signed by a CA we don't trust, PuTTY will bomb out unconditionally with an error, instead of offering a confirmation box. That's an unfinished part which I plan to fix before this goes into a release.
2022-04-22 11:07:24 +00:00
dlgparam dp;
};
static struct ca_config_box *cacfg; /* one of these, cross-instance */
static void cacfg_destroy(GtkWidget *widget, gpointer data)
{
cacfg->window = NULL;
dlg_cleanup(&cacfg->dp);
ctrl_free_box(cacfg->cb);
cacfg->cb = NULL;
New command-line option: 'putty --host-ca'. This causes PuTTY to bring up just the host CA configuration dialog box, and shut down once that box is dismissed. I can imagine it potentially being useful to users, but in the first instance, I expect it to be useful to _me_, because it will greatly streamline testing changes to the UI of that dialog!
2022-05-01 07:22:44 +00:00
if (cacfg->quit_main)
gtk_main_quit();
Initial support for host certificates. Now we offer the OpenSSH certificate key types in our KEXINIT host key algorithm list, so that if the server has a certificate, they can send it to us. There's a new storage.h abstraction for representing a list of trusted host CAs, and which ones are trusted to certify hosts for what domains. This is stored outside the normal saved session data, because the whole point of host certificates is to avoid per-host faffing. Configuring this set of trusted CAs is done via a new GUI dialog box, separate from the main PuTTY config box (because it modifies a single set of settings across all saved sessions), which you can launch by clicking a button in the 'Host keys' pane. The GUI is pretty crude for the moment, and very much at a 'just about usable' stage right now. It will want some polishing. If we have no CA configured that matches the hostname, we don't offer to receive certified host keys in the first place. So for existing users who haven't set any of this up yet, nothing will immediately change. Currently, if we do offer to receive certified host keys and the server presents one signed by a CA we don't trust, PuTTY will bomb out unconditionally with an error, instead of offering a confirmation box. That's an unfinished part which I plan to fix before this goes into a release.
2022-04-22 11:07:24 +00:00
}
New command-line option: 'putty --host-ca'. This causes PuTTY to bring up just the host CA configuration dialog box, and shut down once that box is dismissed. I can imagine it potentially being useful to users, but in the first instance, I expect it to be useful to _me_, because it will greatly streamline testing changes to the UI of that dialog!
2022-05-01 07:22:44 +00:00
static void make_ca_config_box(GtkWidget *spawning_window)
Initial support for host certificates. Now we offer the OpenSSH certificate key types in our KEXINIT host key algorithm list, so that if the server has a certificate, they can send it to us. There's a new storage.h abstraction for representing a list of trusted host CAs, and which ones are trusted to certify hosts for what domains. This is stored outside the normal saved session data, because the whole point of host certificates is to avoid per-host faffing. Configuring this set of trusted CAs is done via a new GUI dialog box, separate from the main PuTTY config box (because it modifies a single set of settings across all saved sessions), which you can launch by clicking a button in the 'Host keys' pane. The GUI is pretty crude for the moment, and very much at a 'just about usable' stage right now. It will want some polishing. If we have no CA configured that matches the hostname, we don't offer to receive certified host keys in the first place. So for existing users who haven't set any of this up yet, nothing will immediately change. Currently, if we do offer to receive certified host keys and the server presents one signed by a CA we don't trust, PuTTY will bomb out unconditionally with an error, instead of offering a confirmation box. That's an unfinished part which I plan to fix before this goes into a release.
2022-04-22 11:07:24 +00:00
{
if (!cacfg) {
cacfg = snew(struct ca_config_box);
memset(cacfg, 0, sizeof(*cacfg));
}
if (cacfg->window) {
/* This dialog box is already displayed; re-focus it */
gtk_widget_grab_focus(cacfg->window);
return;
}
dlg_init(&cacfg->dp);
for (size_t i = 0; i < lenof(cacfg->scs.sc); i++) {
cacfg->scs.sc[i].action = SHORTCUT_EMPTY;
}
cacfg->cb = ctrl_new_box();
setup_ca_config_box(cacfg->cb);
cacfg->window = our_dialog_new();
gtk_window_set_title(GTK_WINDOW(cacfg->window),
"PuTTY trusted host certification authorities");
gtk_widget_set_size_request(
cacfg->window, string_width(
"ecdsa-sha2-nistp256 256 SHA256:hsO5a8MYGzBoa2gW5"
"dLV2vl7bTnCPjw64x3kLkz6BY8"), -1);
/* Set up everything else */
for (int i = 0; i < cacfg->cb->nctrlsets; i++) {
struct controlset *s = cacfg->cb->ctrlsets[i];
GtkWidget *w = layout_ctrls(&cacfg->dp, NULL, &cacfg->scs, s,
GTK_WINDOW(cacfg->window));
gtk_container_set_border_width(GTK_CONTAINER(w), 10);
gtk_widget_show(w);
if (!*s->pathname) {
our_dialog_set_action_area(GTK_WINDOW(cacfg->window), w);
} else {
our_dialog_add_to_content_area(GTK_WINDOW(cacfg->window), w,
true, true, 0);
}
}
cacfg->dp.data = cacfg;
cacfg->dp.shortcuts = &cacfg->scs;
cacfg->dp.lastfocus = NULL;
cacfg->dp.retval = 0;
cacfg->dp.window = cacfg->window;
dlg_refresh(NULL, &cacfg->dp);
New command-line option: 'putty --host-ca'. This causes PuTTY to bring up just the host CA configuration dialog box, and shut down once that box is dismissed. I can imagine it potentially being useful to users, but in the first instance, I expect it to be useful to _me_, because it will greatly streamline testing changes to the UI of that dialog!
2022-05-01 07:22:44 +00:00
if (spawning_window) {
set_transient_window_pos(spawning_window, cacfg->window);
Initial support for host certificates. Now we offer the OpenSSH certificate key types in our KEXINIT host key algorithm list, so that if the server has a certificate, they can send it to us. There's a new storage.h abstraction for representing a list of trusted host CAs, and which ones are trusted to certify hosts for what domains. This is stored outside the normal saved session data, because the whole point of host certificates is to avoid per-host faffing. Configuring this set of trusted CAs is done via a new GUI dialog box, separate from the main PuTTY config box (because it modifies a single set of settings across all saved sessions), which you can launch by clicking a button in the 'Host keys' pane. The GUI is pretty crude for the moment, and very much at a 'just about usable' stage right now. It will want some polishing. If we have no CA configured that matches the hostname, we don't offer to receive certified host keys in the first place. So for existing users who haven't set any of this up yet, nothing will immediately change. Currently, if we do offer to receive certified host keys and the server presents one signed by a CA we don't trust, PuTTY will bomb out unconditionally with an error, instead of offering a confirmation box. That's an unfinished part which I plan to fix before this goes into a release.
2022-04-22 11:07:24 +00:00
} else {
gtk_window_set_position(GTK_WINDOW(cacfg->window), GTK_WIN_POS_CENTER);
}
gtk_widget_show(cacfg->window);
g_signal_connect(G_OBJECT(cacfg->window), "destroy",
G_CALLBACK(cacfg_destroy), NULL);
g_signal_connect(G_OBJECT(cacfg->window), "key_press_event",
G_CALLBACK(win_key_press), &cacfg->dp);
}
New command-line option: 'putty --host-ca'. This causes PuTTY to bring up just the host CA configuration dialog box, and shut down once that box is dismissed. I can imagine it potentially being useful to users, but in the first instance, I expect it to be useful to _me_, because it will greatly streamline testing changes to the UI of that dialog!
2022-05-01 07:22:44 +00:00
void show_ca_config_box(dlgparam *dp)
{
make_ca_config_box(dp ? dp->window : NULL);
}
void show_ca_config_box_synchronously(void)
{
make_ca_config_box(NULL);
cacfg->quit_main = true;
gtk_main();
}
Reference in New Issue Copy Permalink